Difference between revisions of "Udev"

From Organic Design wiki
m (Resources)
m (UDev moved to Udev)
 
(One intermediate revision by the same user not shown)
Line 112: Line 112:
 
*[http://docs.blackfin.uclinux.org uclinux docs]
 
*[http://docs.blackfin.uclinux.org uclinux docs]
 
*[http://vrfy.org/log/recent-state-of-udev.html Recent state of udev]
 
*[http://vrfy.org/log/recent-state-of-udev.html Recent state of udev]
[[Category:Peerix]]
+
[[Category:Peerix]]{{lowercase}}

Latest revision as of 21:45, 16 November 2008

udev deals with hotplugging (and coldplugging) devices such as USB key drives, usb cameras and firewire drives. Cold-plugging means connecting or disconnecting a device while the host machine is powered off.

Configuration

udev takes messages from the kernel (2.6 onwards) and processes them in userland. The structure of the config file is very simple. It defines how you will bind kernel messages to actions by way of pattern matching.

Hotplugging and the Graphical User Interface

It is important to provide feedback to the user when they plug or unplug a device. It is suggested that both visual and audible feedback be provided where possible. The latency for plugging is about 1 second. For unplugging the response is almost immediate.

USB

This document may be useful Mounting and unmounting removable devices in linux

USB devices live at /proc/bus/usb. When a device is plugged this file is updated. Here is an example of the file:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-2-386 uhci_hcd
S:  Product=Intel Corp. 82801AA USB
S:  SerialNumber=0000:00:1f.2
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0d7d ProdID=1300 Rev= 0.50
S:  Product=USB2.0 FlashDisk
S:  SerialNumber=1D4402000054
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

This computer has only one external USB device plugged in (USB2.0 FlashDisk). The other entry is the host controler (Intel Corp. 82801AA USB).

Resources


udev is a program that monitors kernel events and responds by creating devices in the /dev filesystem. udev may also refer to /sys to fill in any important details into the device naming.

Example

udev is a rules engine it's behavour is determined by it's configuration file. From the man page:

BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="OEM 0815", NAME="disk1"
BUS="usb", SYSFS{serial}="W09090207101241330", NAME="lp_color"
BUS="scsi", SYSFS{vendor}="IBM", SYSFS{model}="ST336", NAME="boot%n"
BUS="pci", ID="00:0b.0", NAME="dsp"
BUS="usb", PLACE="2.3", NAME="mouse1"
KERNEL="ttyUSB1", NAME="pda", SYMLINK="palmtop handheld"
BUS="usb", SYSFS{model}="XV3", NAME="video%n", SYMLINK="webcam%n"
KERNEL="sr*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="scd*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="pcd*", NAME="%k", SYMLINK="cdrom%e"
KERNEL="hd[a-z]", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom", NAME="%k", SYMLINK="cdrom%e"

Naming conventions

As you can see it is possible to perform almost any kind of translation between kernel device names and the /dev file system with interaction with /sys. The question is: Is any kind of translation desirable or even necessary? Why not use the kernel device names and the append the kernel number (%n)? Perhaps it is better to keep these device names "raw" at this level, and abstract them through the user interface.

For example: Someone plugs in the removable USB device. Why not just create in /dev a device with the kernel name? It is then up to the interface to pattern match against *usb* or whatever in the /dev to see if there is a device to allow the user to interact with.

This method is along the lines of treating devices as symbols in the network, and if they all have the same kernel ids it will be much easier to share resources.

Different conventions, same device

What follows was taken from here. It shows how devices can be referenced in different contexts whether by hardware id, volume label, bus path or uuid.


  /dev/disk
  |-- by-id
  |   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B -> ../../sda
  |   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part1 -> ../../sda1
  |   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part6 -> ../../sda6
  |   |-- scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B-part7 -> ../../sda7
  |   |-- usb-Generic_STORAGE_DEVICE_02773 -> ../../sdd
  |   `-- usb-Generic_STORAGE_DEVICE_02773-part1 -> ../../sdd1
  |-- by-label
  |   |-- Photos -> ../../sdd1
  |   |-- SUSE10 -> ../../sda7
  |   `-- devel -> ../../sda6
  |-- by-path
  |   |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
  |   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
  |   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part6 -> ../../sda6
  |   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part7 -> ../../sda7
  |   |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sr0
  |   |-- usb-02773:0:0:2 -> ../../sdd
  |   |-- usb-02773:0:0:2-part1 -> ../../sdd1
  `-- by-uuid
      |-- 159a47a4-e6e6-40be-a757-a629991479ae -> ../../sda7
      |-- 3e999973-00c9-4917-9442-b7633bd95b9e -> ../../sda6
      `-- 4210-8F8C -> ../../sdd1


Proposed udev rule

This should encompass all possible devices and simply populate /dev with devices with kernel device names.


to come

See also