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.

A few years later, at Foo Camp:

rml at Foo Camp
My Foo Camp Picture

Nice to see I have not yet grown up.

Tuesday, November 16, 2004

Utter Domination

I won't mention that, despite drafting last, I am currently first in our office fantasy football league.

Betsy's desktop

P.S. Luis may be in last place in fantasy football, but he is in first place in real-world managing.

Tuesday, November 2, 2004

I Voted Today

I wrote an "applet" to display the current Homeland Security Threat Level:

Homeland Security

It is in module homeland in GNOME CVS. It is a little rough, a quick hack, but it works. See the TODO.

Update! Thanks to the power of open source, now with color coding and tooltips:

Homeland Security, take two

Monday, November 1, 2004

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.