If You C Jordan

I know it is stylish to scream Vote! and some people even threaten your life over exercising suffrage, but my feelings are less grand, certainly less drastic. If you are informed and have an opinion, please vote. Apathy is not an excuse.

I used to be a member of the Royal Family:

rml in a suit

Using the kernel event layer (triumphant debut in 2.6.10-rc1) is easy:

int kobject_uevent (struct kobject *kobj, enum kobject_action action, struct attribute *attr)

kobj specifies the kobject that is to emit this signal. kobjects are like gobjects but for the kernel. They form the basis of sysfs, where each directory in sysfs is associated with a kobject and consequently sysfs is actually a filesystem representation of an object hierarchy. So we are modeling the signals as originating from a specific sysfs path. As an example, if we were sending out a kernel event related to a specific partition, we might pass &bdev->bd_part->kobj here, which might correspond to /sys/block/hda/hda2.

action is the verb describing this signal. The enum is defined in <linux/kobject_uevent.h>. If our partition above was being mounted, we might pass KOBJ_MOUNT. The enums are mapped to strings when the kevent is sent. The intention behind the enum is to provide some modicum of type safety and to prevent the proliferation of strings with similar meanings, typos, and so on.

attr is an optional argument specifying a sysfs attribute (a specific file in sysfs). The rationale is that sysfs files can represent the "payload" behind the signal. If the signal is to have associated data, we should represent it in sysfs. The kernel event layer then becomes a mechanism for asynchronous notification to user-space of changes in sysfs. This option can be NULL if there is no associated attribute file. There is a generic KOBJ_CHANGE to represent a change in a sysfs attribute if no better verb exists.

kobject_uevent returns zero on success, nonzero on failure. It can sleep (as it allocates memory). A sister function, kobject_uevent_atomic, does not sleep but, since it allocates memory via GFP_ATOMIC, use of it should be minimized.

Retrieving the events in user-space is as simple as reading the NETLINK_KOBJECT_UEVENT netlink socket. Kay has some nice examples of tying the event layer into D-BUS. Kay is also working on a version of hotplug that runs as a daemon, grabbing kevents, instead of via /sbin/hotplug up-calling. We still need to figure out the kevent-DBUS-HAL relationship. It might make more sense for HAL to intercept the events directly.

I think that the modeling of events as signals emitted by kobjects (sysfs paths) and the use of attributes (sysfs files) as the payloads is a rather unique and interesting approach to asynchronous kernel-to-user communication. I am pleased with the final iteration in 2.6 and I hope that this event paradigm pays off.