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:

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.