Udev : Utilisation d'un socket pour parler avec les devices kernel
Contents
1 Introduction
udev est un gestionnaire de périphériques remplaçant devfs sur les noyaux Linux de la série 2.6. Sa fonction principale est de gérer les périphériques dans le répertoire /dev.
udev s'exécute en mode utilisateur et dialogue avec hotplug qui lui s'exécute en mode noyau. Il utilise et stocke des informations qu'il a découvert dans /sys. Il permet lors de la détection d'un matériel de lui attribuer un nom de device, de créer des liens symboliques ou encore exécuter un progromme lorsqu'une action arrive sur un ou plusieurs périphériques.
udev a un socket d'ouvert sur la machine et le noyau informe udev des nouveaux périphériques via ce socket.
Voici comment fonctionne udev :
- Le kernel découvre un périphérique et renvoit sont status à sysfs
- udev est informé de ce nouvel évènement via un socket netlink
- udev créer le périphérique (/dev/device) et/ou lance un programme (définit dans les règles udev)
- udev informe hald (Hardware Abstraction Layer Deamon) de cet évènement via un socket
- La HAL (Hardware Abstraction) récupère les informations de ce périphérique
- La HAL construit les structures d'objets liés au périphérique avec les informations récupérées précédemment et via d'autres ressources
- La HAL broadcast les évènements a travers D-Bus
- Une application userland regarde ce type d'évènements pour y traiter les informations ensuite
2 Utilisation
Il n'y a pas grand chose en réalité à faire avec udev pour un fonctionnement normal puisqu'il est généralement corectement paramétrer par la distribution sur laquelle vous vous trouvez. Toutefois vous aurez peut être envie de jouer avec et de personnaliser un peu votre système.
2.1 Monitoring
On peut monitorer udev en utilisant la commande 'udevmonitor'. Si par exemple je souhaite monitorer le branchement de mon iPhone :
3 Les règles
Ls règles udev sont définies dans /etc/udev/rules.d, ce qui veut dire que vous pouvez les customiser ou bien créer vos propres règles.
Voici les options du fichier de configuration udev.conf :
- udev_root : là ou les devices doivent être créer (/dev)
- udev_rules : là ou sont les règles (/etc/udev/rules.d/*.rules)
- udev_log : définit le niveau de verbosité
3.1 Créer ses règles
Nous allons créer un fichier avec l'extension ".rules" pour qu'ils soient pris en compte par udev (/etc/udev/rules.d/*.rules), sous la forme :
<match-key><operator>value, <assignment-key><operator>value, <action><operator>value
qui peut correspondre à quelque chose comme :
PROGRAM=="script_a_lancer" RESULT=="ce_qui_doit_etre_retourner_par_PROGRAM_pour_validation"
Voici un exemple :
/etc/udev/rules.d/75-iphone.rules |
BUS=="usb", SYSFS{product}="iPhone", SYMLINK+="iphone" |
Je demande à udev que lorsqu'il détecte la présence d'un iPhone sur un port USB, il créer automatiquement un lien symbolique dans /dev qui portera le nom de '/dev/iphone'.
Pour trouver des informations sur lesquelles nous allons pouvoir construire nos règles udev, il va falloir dans un premier temps récupérer les informations sur le matériel. Tout d'abord prenons l'informations (DEVNAME) sur le chemin du device que nous connaissons à l'aide du monitoring :
udevinfo |
> udevinfo -q path -n /dev/bus/usb/001/007 /class/usb_device/usbdev1.7 |
Cette commande nous a sorti le chemin dans /sys et nous allons l'utiliser maintenant pour récupérer toutes les informations disponibles :
Je viens donc d'obtenir l'information qui m'intéressait sur mon périphérique.
Nous allons dire à udev de recharger ses règles, afin qu'il prenne notre nouvelle règle en compte (sans avoir besoin de rebooter la machine) :
udevcontrol |
udevcontrol reload_rules |
Ou suivant la version de l'OS, ceci fonctionne également :
udevadm control --reload-rules |
3.1.1 Avec du iSCSI
Lorsque l'on utilise du iscsi, on peut récupérer les informations comme ceci :
scsi_id |
> scsi_id -g -x -s /block/sda ID_VENDOR=ATA ID_MODEL=WDC_WD1600AAJS-6 ID_REVISION=58.0 ID_SERIAL=SATA_WDC_WD1600AAJS-_WD-WMAS20873789 ID_TYPE=disk ID_BUS=scsi |
Les équivalents pour l'USB ou l'ATA sont :
/lib/udev/ata_id /dev/hdx /lib/udev/usb_id /dev/sdx |
3.2 Explications sur la créations de règles
Maintenant, vous allez me dire que c'est bien beau, mais tu n'explique pas plus que ça comment tu fais pour construire cette règle ! Nous allons détailler ici (beaucoup grace au man).
3.2.1 Correspondances sur les clés
Sachez donc qu'il y a des opérateurs pour définir les règles de correspondance udev et celles ci sont faites pour matcher des propriétés de devices (certaines de ces propriétés matchent le device parent dans sysfs) :
Description | Operator |
---|---|
Compare for equality | == |
Compare for inequality | != |
Assign a value to a key. Keys that represent a list, are reset and only this single value is assigned | = |
Add the value to a key that holds a list of entries | += |
Assign a value to a key finally; disallow any later changes, which may be used to prevent changes by any later rules | := |
Et voici les éléments qui peuvent être utilisés pour la correspondance :
Description | Operator |
---|---|
Match the name of the event action | ACTION |
Match the name of the device | KERNEL |
Match the devpath of the device | DEVPATH |
Match the subsystem of the device | SUBSYSTEM |
Match the name of the event action | ACTION |
Search the devpath upwards for a matching device subsystem name | BUS |
Search the devpath upwards for a matching device driver name | DRIVER |
Search the devpath upwards for a matching device name | ID |
Search the devpath upwards for a device with matching sysfs attribute values. Up to five SYSFS keys can be specified per rule. All attributes must match on the same device. Trailing whitespace in the attribute values is ignored, if the specified match value does not contain trailing whitespace itself. | SYSFS{filename} |
Match against the value of an environment variable. Up to five ENV keys can be specified per rule. This key can also be used to export a variable to the environment. | ENV{key} |
SExecute external program. The key is true, if the program returns without exit code zero. The whole event environment is available to the executed program. The program’s output printed to stdout is available for the RESULT key | PROGRAM |
Match the returned string of the last PROGRAM call. This key can be used in the same or in any later rule after a PROGRAM call | RESULT |
Vous pouvez utiliser des matching patterns, pour vos correspondances :
Description | Operator |
---|---|
Matches zero, or any number of characters | * |
Matches any single character | ? |
Matches any single character specified within the brackets. For example, the pattern string 'tty[SR]' would match either 'ttyS' or 'ttyR'. Ranges are also supported within this match with the '-' character. For example, to match on the range of all digits, the pattern [0-9] would be used. If the first character following the '[' is a '!', any characters not enclosed are matched | [] |
3.2.2 Règles sur l'assignement des clés
Voici maintenant les solutions pour les valeurs :
Description | Operator |
---|---|
The name, a network interface should be renamed to. Or as a temporary workaround, the name a device node should be named. Usually the kernel provides the defined node name, or even creates and removes the node before udev even receives any event. Changing the node name from the kernel's default creates inconsistencies and is not supported. If the kernel and NAME specify different names, an error will be logged. Udev is only expected to handle device node permissions and to create additional symlinks, not to change kernel-provided device node names. Instead of renaming a device node, SYMLINK should be used. Symlink names must never conflict with device node names, it will result in unpredictable behavior | NAME |
The name of a symlink targeting the node. Every matching rule will add this value to the list of symlinks to be created. Multiple symlinks may be specified by separating the names by the space character. In case multiple devices claim the same name, the link will always point to the device with the highest link_priority. If the current device goes away, the links will be re-evaluated and the device with the next highest link_priority will own the link. If no link_priority is specified, the order of the devices, and which one of them will own the link, is undefined. Claiming the same name for a symlink, which is or might be used for a device node, may result in unexpected behavior and is not supported | SYMLINK |
The permissions for the device node. Every specified value overwrites the compiled-in default value | OWNER, GROUP, MODE |
The value that should be written to a sysfs attribute of the event device | ATTR{key} |
Set a device property value. Property names with a leading '.' are not stored in the database or exported to external tool or events | ENV{key} |
Attach a tag to a device. This is used to filter events for users of libudev's monitor functionality, or to enumerate a group of tagged devices. The implementation can only work efficiently if only a few tags are attached to a device. It is only meant to be used in contexts with specific device filter requirements, and not as a general-purpose flag. Excessive use might result in inefficient event handling | TAG |
Add a program to the list of programs to be executed for a specific device. This can only be used for very short running tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Long running tasks need to be immediately detached from the event process itself. If the option RUN{fail_event_on_error} is specified, and the executed program returns non-zero, the event will be marked as failed for a possible later handling. If no absolute path is given, the program is expected to live in /lib/udev, otherwise the absolute path must be specified. Program name and arguments are separated by spaces. Single quotes can be used to specify arguments with spaces |
RUN |
Named label where a GOTO can jump to | LABEL |
Jumps to the next LABEL with a matching name | GOTO |
Import a set of variables as device properties, depending on type:
If no option is given, udev will choose between program and file based on the executable bit of the file permissions |
IMPORT{type} |
Wait for a file to become available or until a 10 seconds timeout expires. The path is relative to the sysfs device, i. e. if no path is specified this waits for an attribute to appear | WAIT_FOR |
Rule and device options :
|
OPTIONS |
3.2.3 Règles de substitutions
Les champs NAME, SYMLINK, PROGRAM, OWNER, GROUP, MODE et RUN supportent les règles de substitutions. Ce sont des builts in pour vous aider à mettre certaines variables :
Description | Operator |
---|---|
The kernel name for this device | $kernel, %k |
The kernel number for this device. For example, 'sda3' has kernel number of '3' | $number, %n |
The devpath of the device | $devpath, %p |
The name of the device matched while searching the devpath upwards for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS. | $id, %b |
The driver name of the device matched while searching the devpath upwards for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS | $driver |
The value of a sysfs attribute found at the device, where all keys of the rule have matched. If the matching device does not have such an attribute, and a previous KERNELS, SUBSYSTEMS, DRIVERS, or ATTRS test selected a parent device, use the attribute from that parent device. If the attribute is a symlink, the last element of the symlink target is returned as the value | $attr{file}, %s{file} |
A device property value | $env{key}, %E{key} |
The kernel major number for the device | $major, %M |
The kernel minor number for the device | $minor, %m |
The string returned by the external program requested with PROGRAM. A single part of the string, separated by a space character may be selected by specifying the part number as an attribute: %c{N}. If the number is followed by the '+' char this part plus all remaining parts of the result string are substituted: %c{N+} | $result, %c |
The node name of the parent device | $parent, %P |
The current name of the device node. If not changed by a rule, it is the name of the kernel device | $name |
The current list of symlinks, separated by a space character. The value is only set if an earlier rule assigned a value, or during a remove events | $links |
The udev_root value | $root, %r |
The sysfs mount point | $sys, %S |
The name of a created temporary device node to provide access to the device from a external program before the real node is created | $tempnode, %N |
The '%' character itself | %% |
$$ | The '$' character itself |
4 Exemples
Voici une petite liste d'exemple pour vous aider à construire des règles :
This always maps a specific USB device (in this case, a pendrive) to /dev/usbpen, which is then set in fstab to mount on /mnt/usbpen:
If for devices with multiple partitions, the following example maps the device to /dev/usbdisk, and partitions 1, 2, 3 etc., to /dev/usbdisk1, /dev/usbdisk2, /dev/usbdisk3, etc.
The above rules are equivalent to the following one:
/etc/udev/rules.d/75-custom-udev.rules |
# Symlink multi-part device SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage" |
It's also possible to omit the NAME and GROUP statements, so that the defaults from udev.rules are used. Meaning that the shortest and simplest solution would be adding this rule:
/etc/udev/rules.d/75-custom-udev.rules |
# Symlink multi-part device SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", SYMLINK+="usbdisk%n" |
This always maps a Olympus digicam to /dev/usbcam, which can be stated in fstab to mount on /mnt/usbcam:
And this maps a Packard Bell MP3 player to /dev/mp3player:
To map a selected usb-key to /dev/mykey and all of other keys to /dev/otherkey:
Note the order of the lines. Since all the USB keys should create the /dev/sd<a||b> node, udev will first check if it is a rules-stated USB-key, defined by serial number. But if an unknown USB-key is plugged, it will create also create a node, using the previously stated generic name, "otherkey". That rule should be the last one in rules file so that it does not override the others.
This is an example on how to distinguish USB HDD drives and USB sticks:
5 Ressources
http://reactivated.net/writing_udev_rules.html
http://www.redhat.com/magazine/002dec04/features/udev/
http://wiki.debian.org/udev
https://wiki.archlinux.org/index.php/Map_Custom_Device_Entries_with_udev