Kernel development

Kernel release status

The current development kernel is 2.5.70, which was released on May 26.

Patches continue to accumulate in Linus's BitKeeper tree; among the almost 900 patches there can be found a fair amount of driver model work (see below), some extensive PCI bus cleanups (dealing with potential race conditions there), the big IDE changeover to taskfile I/O, a new /proc/kallsyms file, support for per-CPU variables in modules, a change the kmalloc_percpu() interface, an Atmel at76c50x wireless driver, a long-sought fix for hanging TCP sessions, an improved slab allocator which performs better in busy, multi-processor situations, some kbuild tweaks, an ALSA update, a set of hash function changes to deal with algorithmic complexity attacks, a FAT filesystem rework (if you have been waiting to be able to create FAT partitions greater than 128GB, this patch is for you), a v850 subarchitecture merge, a RAID update, the removal of the long-deprecated callout TTY device (/dev/cua) support, and several other fixes and updates.

The current stable kernel is 2.4.20. Marcelo released 2.4.21-rc8 on June 10, saying "If nothing really bad happens in 2 days, this becomes final."

There is already a certain amount of disagreement over 2.4.22. In particular, a number of people would like to see an ACPI merge in the release - the current ACPI code has been languishing outside of the official kernel for over a year. Marcelo's response is that 2.4.22 is supposed to come very quickly (within two months) and ACPI is too big, so it will have to wait for 2.4.23. There has been some predictable grumbling over this decision; a lot of people are waiting for a real ACPI merge. Marcelo appears to be uninclined to change his mind, however.

Comments (2 posted)

Reworking system devices

"System" devices, as seen by the Linux device model, are components wired deeply into the core of the system, and which do not sit on a separate bus. Such devices include the CPUs, interrupt controller, timer, etc. They do not behave like most other devices (for example, you cannot open and write to them), and they are usually a vital part of the system as a whole. System devices are easily confused with "platform" devices - things like serial and parallel ports which usually are found on the system motherboard, but which act more like regular peripherals.

Up through 2.5.70, the Linux device model has treated system devices like most other devices. There is a fake "system bus" to which system devices "attach", and the usual driver methods are expected to be present. But, as Patrick Mochel noted in his patch reorganizing the system device API, "System devices are special, and after two years of listening to Linus preach this, it finally sunk in enough to do something about."

System devices are special in a number of ways. You generally know that they have to be present (you don't have to go probing for them), and there is little point in trying to load a driver for them. When dealing with power transitions (suspending or resuming the system), system devices need to be the last to shut down and the first to restart. They have weird interfaces that no other devices have; consider, for example, controlling CPU frequency policy. System devices, in other words, need to be treated in their own, particular way.

So, as of 2.5.71, there is a new API and user-space interface for working with system devices. There is a new include file (<linux/sysdev.h>) which defines a class type for system devices:

struct sysdev_class {
	struct list_head	drivers;

	/* Default operations for these types of devices */
	int	(*shutdown)(struct sys_device *);
	int	(*save)(struct sys_device *, u32 state);
	int	(*suspend)(struct sys_device *, u32 state);
	int	(*resume)(struct sys_device *);
	int	(*restore)(struct sys_device *);
	struct kset		kset;
};

A new type of system device is set up by filling in one of those structures and passing it to sysdev_class_register(). An actual system device is then created by filling in one of:

struct sys_device {
	u32		id;
	struct sysdev_class	* cls;
	struct kobject		kobj;
};

and passing it to sys_device_register(). The class-specific suspend and resume functions will now be called at the right times for that device, and a new sysfs directory will show up under /sys/devices/system with a default set of attributes.

For more complicated sorts of devices, it is still possible to register one or more "drivers" which add functionality. There is yet another structure to fill in:

struct sysdev_driver {
	struct list_head	entry;
	int	(*add)(struct sys_device *);
	int	(*remove)(struct sys_device *);
	int	(*shutdown)(struct sys_device *);
	int	(*save)(struct sys_device *, u32 state);
	int	(*suspend)(struct sys_device *, u32 state);
	int	(*resume)(struct sys_device *);
	int	(*restore)(struct sys_device *);
};

A call to sysdev_driver_register() will associate this driver with a specific system device class. Multiple drivers can be registered; each will be given a chance to respond to events involving devices in the given class. The add() and remove() methods allow the driver to respond to the creation or destruction of system devices - generally by adding or removing attributes to their sysfs entries. Thus, "drivers" in this context take on the functions handled by "interfaces" elsewhere in the driver model.

The new system device mechanism is thus a sort of hybrid combination of the device, driver, bus, and class structures used by "regular" devices. The new code is, perhaps, a step in the right direction, but it clearly illustrates one thing: the Linux device model still has not stabilized, and may not for a while yet. The device model is a major change to how things are done in the kernel, and the developers are still feeling around for the best way of doing things.

Comments (1 posted)

The Kernel Janitor patchsets

The Kernel Janitor project is getting organized, as can be seen in this announcement regarding the new "KJ" patchset series. Essentially, this patchset is an attempt to pull together and organize the numerous janitorial patches out there. With luck, the result should be cleaner kernel.

Janitorial patches can have a difficult path into the kernel. Anybody who has sent patches to Linus knows that they often disappear into the void, never to be heard from again. Getting patches applied can require a fair amount of persistence and effort. The patches must be updated to apply cleanly to each new kernel release and resubmitted; eventually you may catch Linus in the right mood, and he'll either apply the patch or tell you why he won't.

Carrying patches forward and resubmitting them can be a significant load for kernel developers. It can be hard enough when the patch does something new and exciting. But even the most determined janitor can get discouraged with maintaining cleanup patches which seem to never get applied. It is not uncommon for developers to simply give up on patches after a few iterations.

Mechanisms like the Trivial Patch Monkey can help. The Monkey will resubmit patches to Linus after every new kernel release as long as (1) they still apply, and (2) they do not get merged. This system lets developers forget about the really boring patches, on the assumption that they will eventually go in.

Many cleanup patches are not trivial enough for the Trival Patch Monkey, however. The new KJ patchset appears to be an attempt to create a mechanism for such patches. To be included in -kj, a patch must be approved by at least two kernel janitors project developers (how they decide who is in the club is unspecified) and must not be vetoed by anybody. After a trouble-free week in -kj, patches can be forwarded on to the top-level tree maintainers.

The first patch set in this series is 2.5.70-bk13-kj.

Comments (none posted)

Inside the Linux kernel debugger (developerWorks)

The developerWorks site has posted a detailed tutorial on the KDB kernel debugger. "In this article we'll start with information on downloading KDB patches, applying them, (re)compiling the kernel, and starting KDB. Then we'll get into the KDB commands and review some of the more often-used commands. Finally, we'll look at some details about the setup and display options."

Comments (none posted)