HEADS UP - kern_udev, udevd and libdevattr

[Alex <ahornung@xxxxxxxxx>]

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