I’m thinking of a program that (like UDEV) would monitor D-Bus events and if something is plugged in that doesn’t have a rule apply to it (not sure how to do that) it could allow a rule to be created using a GUI form.

I’m thinking a Ruby program using GTK+ to parse the sysfs tree for a given device and present that in some kind of form.

The first thing you need to know about UDEV (like fight club) is that nobody ever talks about UDEV. At least the things you will find on the web are not talking about the current state of UDEV, and so they are mostly all wrong. This one http://reactivated.net/writing_udev_rules.html is good. Using man udev is good too.

What is UDEV? It is a user space program that trys to solve the issues with hot-plug devices and the creation of /dev device nodes. This has been a problem for linux and unix-es in general in that static device nodes in the file system and major/minor device numbers were an idea created in a time before hot plug. The 2.6 kernel with sysfs and the udev program work together to make these dynamic. In general the kernel is responsible for seeing devices on the various busses come and go, and it reports all that it knows about them in the pseudo file system sysfs, and then executes a user program who’s path has been set in a procfs variable.  Udev is usually this program, and picks up where the kernel leaves off, creating device nodes and starting up necessary daemons.  This splits the responsibility so that policy issues such as device node naming and locations are not hard coded inside the kernel.

The way UDEV creates a device node (or does anything) is through a set of rule files. These files are kept in /etc/udev/rules.d and like init.d it uses the file system sort order when processing these rules so you name your rule file starting with a number such that you can control the order of rule application. A rule file contains one or more rules, each rule consisting of EXACTLY one line of text. On this line of text you write a series of key value pairs separated by commas to control UDEV behavior. The keys come in two flavors, match and assignment. Match keys are used to constrain your rule to only apply to what you want it to, and assignment keys are used to cause something to happen when your rule matches. When matching a rule, all of your match keys must match, and the match key values can use shell style regex symbols.

The most useful match keys are:

KERNEL==”value” where value is the kernel name of the device like KERNEL==”tty[0-9]*”

SUBSYSTEM==”value” where value is the kernel subsystem name the device is on like SUBSYSTEM==”scsi”

ATTR{sysfs name}==”value” where sysfs name is a file name of an entry in the sysfs file system, and value is the contents of that file like ATTRS{product}==”DeLorme USB Earthmate”

The most useful assignment keys are:

NAME=”node name” where node name is the file name to create the device node with like NAME=”hwrng”

SYMLINK=”link name” where link name will be a symbolic link to the device node like SYMLINK+=”earthmate-gps”

OWNER=”user”, GROUP=”group”, MODE=”octal mode” where user, group, and mode are used to set the device node permissions

RUN=”daemon path” where daemon path is a path to an executable to run

It is imortant to note that all the rules that match will cause the assignment keys to evaluate, so you can write partial rules that match a subsection of devices followed by specific rules to match a specific device. In these cases you can use the operator += rather than = to accumulate values to keys.

So for example my Delorme Earthmate GPS rule became:

#earthmate gps
ATTRS{product}==”DeLorme USB Earthmate”, MODE==”664″, SYMLINK+=”earthmate-gps”, RUN==”/usr/sbin/gpsd/dev/earthmate-gps”

This creates a symlink to the device node that UDEV  creates called earthmate-gps in the /dev directory, sets the permissions of the device node so that others can read it, and executes the daemon gpsd passing the device node symlink as an argument.

I put that line into the file /etc/udev/rules.d/10-local.rules. How did I figure out what to say in the rule? The first place to look is in your system log when you plug in a new device. It will dump out a bunch of information and you can decide what you want to match on. The other thing you can do is to take a look in the sysfs for the device to see all of its info, or use udevinfo to dump out the sysfs info like this for example: udevinfo -a -p /devices/pci0000:00/0000:00:1d.3/usb5/5-2/5-2:1.0/ttyUSB0/tty/ttyUSB0

Another useful utility is udevtest, this will show what UDEV would do with your rule without actually doing it. udevinfo and udevtest are actually simlinks to the udevadm utilty (it checks argv[0] to know what sub command to run ala busybox) so man udevadm will tell you how to work those.