Difference between revisions of "Udev"

From Organic Design wiki
(USB)
m (UDev moved to Udev)
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Thanks to HotPlug and /proc it has never been easier for software to determine the state of devices plugged into the system.
+
[[Wikipedia:Udev|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.
 +
*[http://downloads.linuxfromscratch.org/ Lots of examples]
 +
 
 +
== 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 ==
 
== 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:
 
USB devices live at /proc/bus/usb. When a device is plugged this file is updated. Here is an example of the file:
 
<pre>
 
<pre>
Line 27: Line 36:
 
This computer has only one external USB device plugged in (USB2.0 FlashDisk). The other entry is the host controler (Intel Corp. 82801AA USB).
 
This computer has only one external USB device plugged in (USB2.0 FlashDisk). The other entry is the host controler (Intel Corp. 82801AA USB).
  
== Firewire and others ==
+
== Resources ==
These all work in a similar way. It is a simple matter to parse the /proc files to extract whatever relevant data is needed to feed into the UI.
+
*[[Example hotplug transaction]]
 +
*[http://linux-hotplug.sourceforge.net/ Linux Hotplug project]
 +
*[http://lkml.org/lkml/2005/2/10/179 Best of all: Hotplug in C]
 +
*[http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/uevent_listen.c udev in c]
 +
*[http://www.buberel.org/linux/usb-automounter.php Scripts to auto-mount usb devices]
 +
*[http://www.bangmoney.org/presentations/hotplug/ Useful tutorial on hotplugging]
 +
 
  
== Events ==
+
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.
Hotpug also includes a very useful feature that allows you to bind a program to a specific hotplug event. This means the OS can be notified when something happens (eg you plug in your USB memory stick).
 
  
In the directory /etc/hotplug.d is a buch of directories that represent all the kinds of devices that may be hotplugged.
+
== Example ==
 +
udev is a rules engine it's behavour is determined by it's configuration file. From the man page:
 
<pre>
 
<pre>
drwxr-xr-2 root root 4096 2004-09-04 06:15 chandev
+
BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="OEM 0815", NAME="disk1"
drwxr-xr-2 root root 4096 2005-05-11 04:39 default
+
BUS="usb", SYSFS{serial}="W09090207101241330", NAME="lp_color"
drwxr-xr-2 root root 4096 2004-09-04 06:15 dock
+
BUS="scsi", SYSFS{vendor}="IBM", SYSFS{model}="ST336", NAME="boot%n"
drwxr-xr-2 root root 4096 2004-09-04 06:15 ieee1394
+
BUS="pci", ID="00:0b.0", NAME="dsp"
drwxr-xr-2 root root 4096 2004-09-04 06:15 input
+
BUS="usb", PLACE="2.3", NAME="mouse1"
drwxr-xr-2 root root 4096 2004-09-04 06:15 net
+
KERNEL="ttyUSB1", NAME="pda", SYMLINK="palmtop handheld"
drwxr-xr-x  2 root root 4096 2004-09-04 06:15 pci
+
BUS="usb", SYSFS{model}="XV3", NAME="video%n", SYMLINK="webcam%n"
drwxr-xr-x  2 root root 4096 2004-09-04 06:15 scsi
+
KERNEL="sr*", NAME="%k", SYMLINK="cdrom%e"
drwxr-xr-x  2 root root 4096 2005-05-27 05:59 usb
+
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"
 +
</pre>
 +
 
 +
== 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 [http://vrfy.org/log/recent-state-of-udev.html here]. It shows how devices can be referenced in different contexts whether by hardware id, volume label, bus path or uuid.
 +
<pre>
 +
 
 +
  /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
 +
 
 +
 
 +
</pre>
 +
 
 +
== Proposed udev rule ==
 +
This should encompass all possible devices and simply populate /dev with devices with kernel device names.
 +
<pre>
 +
 
 +
to come
 
</pre>
 
</pre>
'''Example:'''
 
I want to run a script when the USB device is plugged in. So I put some kind of executable in the usb directory and suffix it with '''.hotplug'''.
 
== Resources ==
 
  
[http://linux-hotplug.sourceforge.net/ Linux Hotplugging]
+
== See also ==
 +
*[http://docs.blackfin.uclinux.org uclinux docs]
 +
*[http://vrfy.org/log/recent-state-of-udev.html Recent state of udev]
 +
[[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