Dynamic Device Handling on the Modern Desktop David Zeuthen Kay Sievers Red Hat, Inc. Novell, Inc. [email protected] [email protected] Abstract has received, it can reflect that change accord- ingly or in response request a specific action to be taken for a specific device. Today, where almost all devices can be added and removed from a running system, the whole system environment needs to dynami- cally adopt to such changes. It creates the need The Path of an Event to move from static device specific configura- tions given at install time to policy based run- The core of the Linux kernel keeps the control time device configuration and change propaga- over the interfaces where devices can be con- tion troughout the whole system including cur- nected and disconnected at runtime. The ker- rently running system services and end user ap- nel drivers create or destroy internal device in- plications. stances, to handle and represent devices. These device instances are exported through the spe- cial filesystem sysfs. Most of the directories in sysfs represent a device and the files in the di- Architectural Overview rectories are properties or methods to request a specific action of the device: The Linux kernel 2.6 exports almost all inter- esting internal device state in a special filesys- /sys/class/block/sda |-- dev tem and sends out events for every change. |-- device -> ../../devices/pci0000:00/\ Udev and HAL as system-wide services are 0000:00:1f.2/host0/target0:0:0/0:0:0:0 ... picking up these device events, possibly re- | |-- read_ahead_kb quest more information from the device itself | ‘-- scheduler |-- range or merge available information stored on the |-- removable system. A global list of devices, including |-- sda1 | |-- dev the whole device context is maintained and | |-- size made available to every possible consumer. All | |-- start | |-- stat changes to that list are propagated over a sim- | ‘-- uevent ple inter-process-communication (IPC) inter- ‘-- uevent face. Applications can subscribe to a specific class of changes and adapt itself according to The hierachy of the device directories repre- that. Based on the notification the application sent the dependency of the devices given by 342 • Dynamic Device Handling on the Modern Desktop KERNEL=="mice", NAME="input/$kernel_name" the hardware itself and the logical stacking con- ACTION=="add", MODALIAS=="?*", \ structed by the kernel driver core. Every de- RUN+="/sbin/modprobe $modalias" SUBSYSTEM=="scsi_device", ACTION=="add", \ vice is identified by its filesystem path, called RUN+="/sbin/modprobe sg" the devpath. Everytime a device is added or KERNEL="sda[0-9]", \ removed an uevent is sent out over a kernel IMPORT{program}="/sbin/vol_id --export $tempnode" netlink socket: ENV{ID_FS_UUID}=="?*", \ SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}" RUN+="socket:/org/freedesktop/hal/udev_event" add@/class/input/devices/input5 ACTION=add Udev rules can specify the name of the de- DEVPATH=/class/input/devices/input5 SUBSYSTEM=input vice node to be created, request programs to SEQNUM=1166 be executed to import additional data into the ... event environment, or run external programs to setup or initialize a device, or request a match- A raw message send over the socket looks like ing module to be loaded into the kernel. Rules this: can also pass the whole event udev has received from the kernel, including possibly added data recv(3,"add@/class/input/devices/input5\0 collected from the device or system configu- ACTION=add\0 DEVPATH=/class/input/devices/input5\0 ration by executing a program or passing the SUBSYSTEM=input\0SEQNUM=1166\0 event over a domain socket. CLASS=/class/input/devices\0 PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.1/\ usb2/2-2/2-2:1.0\0 A simple database with persistent device in- PHYSDEVBUS=usb\0PHYSDEVDRIVER=usbhid\0 PRODUCT=3/46d/c03e/2000\0 formation is maintained by udev and can NAME=\"Logitech USB-PS/2 Optical Mouse\"\0 be queried on demand by any program, but PHYS=\"usb-0000:00:1d.1-2/input0\"\0 UNIQ=\"\"\0EV=7\0KEY=70000 0 0 0 0 0 0 0 0\0 udev does not watch any device state besides REL=103\0", 2048, 0) = 383 adding or removal, and does not get notified about things like battery state changes, media An event sequence for a USB storage device changes in optical drives or card readers. The looks like this: udev infrastructure is limited to very short liv- ing event handling to provide the initial setup add@/devices/pci0000:00/0000:00:1d.7/usb5/5-3 of a device and to reflect the kernels internal add@/devices/pci0000:00/0000:00:1d.7/\ device state to userspace. usb5/5-3/5-3:1.0 add@/class/scsi_host/host13 add@/class/usb_device/usbdev5.15 All advanced subsystem specific knowledge add@/block/sdb add@/class/scsi_generic/sg1 and device monitoring requires a stateful sys- add@/class/scsi_device/13:0:0:0 tem service that has specific knowlege about remove@/class/scsi_generic/sg1 certain classes of hardware, and has access to remove@/class/scsi_device/12:0:0:0 information that can uniquely identify a device. remove@/block/sdb remove@/class/scsi_host/host12 remove@/devices/pci0000:00/0000:00:1d.7/\ usb5/5-3/5-3:1.0 remove@/class/usb_device/usbdev5.14 remove@/devices/pci0000:00/0000:00:1d.7/\ Abstraction and Meaningful Event usb5/5-3 Context The udev [1] daemon listens on the socket and In order to provide applications with more in- matches the given event properties with a set of formation than what the kernel or udev can pro- simple rules: vide, all hardware information is kept in the 2006 Linux Symposium, Volume Two • 343 stateful HAL daemon. Upon startup, the dae- some are read from the actual hardware us- mon scans sysfs and builds a list of device ob- ing ioctl’s, some are merged from device in- jects. It connects to the udev daemon to get formation files and some are related to the ac- notified about further device state changes and updates its internal device representation from tual device configuration. A device object has that on accordingly. Each device object is iden- one or more capabilities and for each capa- tified by a Unique Device Identifier (UDI) and bility a number of properties must be present. each has a number of properties which simply Properties are name spaced; for example the are key/value pairs: capability block requires properties prefixed block udi =’/org/freedesktop/Hal/devices/volume_uuid\ with . Some properties are optional. _c66f3d19_2e10_44c0_9bd6_a8fefc476f7d’ All properties are strongly typed (integer, dou- volume.partition.msdos_part_table_type = 130 info.product = ’SWAP-hda2’ ble, boolean, string, and list of strings are sup- volume.size = 1077511680 ported) and are defined in the HAL specifica- volume.num_blocks = 2104515 volume.block_size = 512 tion [3]. volume.partition.number = 2 info.capabilities = {’volume’, ’block’} Once a device object is constructed it is info.category = ’volume’ matched by one or more device information volume.is_partition = true files to merge additional properties. These files volume.is_disc = false volume.is_mounted_read_only = false are simple XML files that define rules. For ex- volume.is_mounted = false ample: volume.mount_point = ’’ volume.label = ’SWAP-hda2’ volume.uuid = ’c66f3d19-2e10-44c0-\ <match key="storage.model" 9bd6-a8fefc476f7d’ contains="Storage-CFC"> volume.fsversion = ’2’ <merge key="storage.drive_type" volume.fsusage = ’other’ type="string">compact_flash</merge> volume.fstype = ’swap’ </match> storage.model = ’’ block.storage_device = ’/org/freedesktop/Hal/\ devices/storage_serial_NP0JT48299J8’ block.is_volume = true will match all device objects that contains block.minor = 2 the string Storage-CFC in the storage. block.major = 3 block.device = ’/dev/hda2’ model property and set the drive type to be a Compact Flash reader, while These objects are exported via the D-BUS <!-- Sony Ericsson Handys with Memory Stick (Duo) --> <match key="@storage.physical_device:usb.vendor_id" [2] system message bus and each object int="0xfce"> <!-- K750i --> implements the org.freedesktop.Hal. <match key="@storage.physical_device:usb.product_id" int="0xd016"> Device interface with methods that applica- <merge key="storage.drive_type" type="string">memory_stick</merge> tions can use among other things to query prop- </match> erties. On Linux, there is almost a one to one </match> mapping between directories in sysfs and the matches a specific USB device and sets the device objects. When new devices are plugged drive to be of type memory stick. Since in or out, device objects will appear and disap- the HAL specification [3] precisely defines the pear and applications listening on the message properties (including the range of values they bus can be notified. Depending on the device can assume), an application can rely on this object, properties may change values over time, property to e.g. display the right icon for such which also triggers notifications to subscribed drives that reads Compact Flash, MemoryStick applications. and so forth. Most of the properties of HAL device objects To provide up to date information including are derived from the contents of sysfs files, when media is removed, HAL polls device 344 • Dynamic Device Handling on the Modern Desktop files. This is a necessary since e.g. the Linux button.has_state = false kernel (rightly) refuses to do so, since it is not button.type = ’power’ always necessary. udi = ’/org/freedesktop/Hal/devices/acpi_LID’ button.has_state = true button.state.value = true For each device object, HAL provides a suffi- button.type = ’lid’ cient number of properties for consumer appli- cations to make intelligent choices about how to react when new devices are added or re- moved or when properties change. An example and the above snippet shows the representa- is the way HAL abstracts batteries: tion of the power button and the lid button. Since a button can be either pressed or remain udi = ’/org/freedesktop/Hal/devices/acpi_BAT0’ pressed down, the abstraction has the notion of battery.charge_level.percentage = 99 state.