Hi, While I've commited udevd, libdevattr and the corresponding kernel part (kern_udev) some time ago, I've fixed a number of bugs over the past few days and also have added the necessary manual pages and rc.d script now.
The kernel part, kern_udev, provides a way to associate some information to a cdev_t (a device, in general). By default, some information such as name, major, minor, kernel pointer, and driver name is associated, but drivers can voluntarily add more information. I've started adding some of this information for a set of devices, mostly disk devices and the whole disk subsystem for practical use with lvm (to discriminate real disk devices from all other without having to open them and issue an ioctl). This in-kernel API is the only part that still lacks documentation, but I hope to get to it soon. I'll continue work on this by tagging further device subsystems in the kernel and attach other useful information to the device property lists in the different drivers. The udevd daemon connects to /dev/udev (provided by kern_udev) to be able to read out all devices and their associated properties, as well as receive notifications on attaches and detaches (this latter part much like hotplugd, except udevd doesn't do anything with this information directly). The main reason for the existence of udevd is to allow access of libdevattr, which I'll explain in a moment, to the kernel interface without having to implement this multiplexing in the kernel itself. libdevattr is the final part in this puzzle. This library allows access to the device property lists, as well as monitoring events (receiving notifications of attach/detach, ...). It provides a rich set of filtering for both getting a device list and monitoring events. These filters support both wildcards and regular expressions according to regex(3). The API is mostly compatible with Linux' libudev, to minimize the effort required to port stuff relying on libudev, like DeviceKit, etc. Don't get me wrong here: libdevattr *IS NOT* a drop-in replacement for libudev. The functionality *IS* different. The library has a set of man pages that cover pretty much the whole API; devattr(3), udev(3), udev_device(3), udev_monitor(3), udev_enumerate(3). If you are looking for an example of how to use it, look no further than 'devattr_test.c' in lib/libdevattr. While I've hopefully done enough testing, don't be surprised if you use it and bump into some bug. Cheers, Alex Hornung
