Difference between revisions of "Udev"
(merge two separate articles about the same topic) |
(formatting) |
||
| 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] | ||
| − | = Hotplugging and the Graphical User Interface = | + | == 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. | 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]] | This document may be useful [[Mounting and unmounting removable devices in linux]] | ||
| Line 48: | Line 47: | ||
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. | 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 = | + | == Example == |
udev is a rules engine it's behavour is determined by it's configuration file. From the man page: | udev is a rules engine it's behavour is determined by it's configuration file. From the man page: | ||
<pre> | <pre> | ||
| Line 64: | Line 63: | ||
</pre> | </pre> | ||
| − | = Naming conventions = | + | == 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. | 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. | ||
| Line 71: | Line 70: | ||
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. | 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 = | + | == 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. | 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> | <pre> | ||
| Line 103: | Line 102: | ||
</pre> | </pre> | ||
| − | = Proposed udev rule = | + | == Proposed udev rule == |
This should encompass all possible devices and simply populate /dev with devices with kernel device names. | This should encompass all possible devices and simply populate /dev with devices with kernel device names. | ||
<pre> | <pre> | ||
| Line 110: | Line 109: | ||
</pre> | </pre> | ||
| − | = See also = | + | == See also == |
*[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]] | ||
Revision as of 21:40, 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
