Thread: udev handling each of the devices

The behaviour of udev on handling each of the devices can be controlled by using udev rules. Most of the newer distros ship with a number of default udev rules meant for hardware detection. When deciding how to name a device and which additional actions to perform, udev reads a series of rule files. These files are kept in the jete! udev/rules. d directory, and they all must have the. rules suffix. In a rules file, lines starting with "#" are treated as comments. Every other non-blank line is a rule and rules cannot span multiple lines. The default rules file can be seen at /etc/udev/rules.d/50-udev-default.rules

A rule consists of a combination of matching keys for the device and the action to be done on matching the device. In other words, a rule explains how to find the specific device and what to do when it is found.

The following is the basic syntax of a rule: The following line is a simple udev rule. It tells the udev daemon to create /dev/cdrom and /dev/cdromO softlinks to /dev/hdc whenever it finds /dev/hdc.

It is to be remembered that we can specify multiple rules for a single device and it can be written in multiple . rules files. When a device is plugged in or unplugged, the udev daemon looks through all the .rules files in the /ete!udev/rules. d directory until all matching rules are read and executed.

The following are some of the keys or parameters that can be used for device matching and the actions in a udev rule:



• BUS: matches the bus type of the device; examples of this include PCI, USB or SCSI.

• KERNEL: matches the name the kernel gives the device.

• ID: matches the device number on the bus; for example, the PCI bus ID or the USB device ID.

• PLACE: matches the topological position on the bus, such as the physical port a USB device is plugged in to.

• SYSFS_filename, SYSFS filename: allows udev to match any sysjs device attribute, such as the label, vendor, USB serial number or SCSI UUID. Up to five different sysjs files can be checked in a single rule, with all of the values being required in order to match the rule.

• PROGRAM: allows udev to call an external program and check the result. This key is valid if the program returns successfully. The string returned by the program additionally may be matched with the RESULT key.

• ATTR: different attributes for the device like size, product ID, vendor, etc.

• RESULT: matches the returned string of the last PROGRAM call, This key may be used in any rule following a PROGRAM call.

• RUN: it can be set to some external program that can be executed when a device is detected.

• SYMLINK: for creating symlinks for the matching device.

• ACTION: permits two match conditions 'add' and 'rempve' when a new device is added or removed.

In addition to this, Table 1 lists different operators you can use with each of th\, keys. Now the question is: how do we collect information about devices?
Writing a rule is, in turn, matching the device by specifying unique bytes about the device, The unique information about the device can be grabbed from sysjs:

Here I have retrieved an attribute size for the device sdal. Now I can use ATTR{sizel=="14336000" to match the device Idevlsdal . To make the job easier, we have a udev utility called udevinjo, which can, be used to collect details about devices and write rules in a very handy way, The following is the udevirifo output for the same Idevlsdal:

As you can see, it returned a lot of information about the device. We will take some of the above lines to make a udev Now the match is ready! You can even create a symlink for the device as Idevlmusicdrive: Alternatively, you can use the following to obtain information about any device name: