Tuesday, November 23, 2004

At university, the main computer science
lab was divided into two sides: half Sun workstations running Solaris and half
Dell workstations running NT (there was a Linux lab elsewhere). The tension
between the two sides was high and rife with rude looks and derogatory
comments. The Unix side, as it was known, held in contempt the Windows side.
We felt Unix superior. How can they get any work done without grep(1)
and sed(1) and a real shell and a real editor, we wondered? We were
adamant in our supremecy. How on Earth could they hack in Windows? Maybe they
were just drunk.

Of course we were silly and, to be fair, Solaris was slow as hell and CDE
the ugliest thing I have ever used. Nonetheless, each side continued unabated,
at least until the day that the poster showed up.

It was a gigantic Microsoft poster, parading as some developer reference,
but ultimately a piece of well-placed advertising. And it was on the lab's
Unix side.

What were we to do? Would all our walls soon be plastered with advertising
from the "other side?" Would our Unix workstations be replaced by
Windows machines? I had to act, and act quickly. I, the Unix side's hero,
wrote this tongue-in-cheek slightly pompous letter to the department:

I wish to inquire into the possibility of moving the
Microsoft poster to the "Windows side" of this lab. It currently resides on
the "UNIX side" ... I find the poster's presence a hinderance to enjoying my
UNIX sessions.

...

I ask only to have it moved, not removed. There is plenty of
room on the far-side of the "Windows" wall. I realize this request is odd but
I appreciate considerations into the matter.

The next day, the poster was not moved. Instead, it was gone, absent
entirely from the lab. The rest of the semester continued without major
incident between the two sides. Ah, the silliness of my youth.

This was a year before I nearly failed a test in Operating System Design
(excuse: I had kernels to make preemptive). The following semester, the course
adopted a
textbook that I reviewed and technical edited.

Monday, November 1, 2004

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:

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.