Difference between revisions of "Udev"
m (better examples) |
|||
(9 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
[[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. | [[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== | + | == 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. | 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] | *[http://downloads.linuxfromscratch.org/ Lots of examples] | ||
Line 37: | Line 37: | ||
== Resources == | == Resources == | ||
− | + | *[[Example hotplug transaction]] | |
*[http://linux-hotplug.sourceforge.net/ Linux Hotplug project] | *[http://linux-hotplug.sourceforge.net/ Linux Hotplug project] | ||
− | |||
*[http://lkml.org/lkml/2005/2/10/179 Best of all: Hotplug in C] | *[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.buberel.org/linux/usb-automounter.php Scripts to auto-mount usb devices] | ||
*[http://www.bangmoney.org/presentations/hotplug/ Useful tutorial on hotplugging] | *[http://www.bangmoney.org/presentations/hotplug/ Useful tutorial on hotplugging] | ||
+ | |||
+ | |||
+ | 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: | ||
+ | <pre> | ||
+ | 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" | ||
+ | </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> | ||
+ | |||
+ | == 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.
Contents
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
- Example hotplug transaction
- Linux Hotplug project
- Best of all: Hotplug in C
- udev in c
- Scripts to auto-mount usb devices
- Useful tutorial on hotplugging
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