See also: last week's Kernel page.

Kernel development

Your editor's subjective impression is that the -test10 prepatch is one of the more stable of the recent kernels; -test8 and -test9 were rather rough in spots.

The latest 2.4 jobs list was posted by Ted Ts'o at ALS.

The current stable kernel release is 2.2.17. The stream of 2.2.18 prepatches has resumed with 2.2.18pre16. Among other things, this version of the patch contains the NFSv3 server patches, completing the integration of the new NFS code. There is much rejoicing in NFSland. There is also a large M68k update that didn't get put in entirely correctly, leading to some header files going into the wrong place. Presumably pre17 will fix that little problem.

How to get a faster kernel update cycle? The 2.4 kernel is late, the press is giving us grief, and people are wondering how the stable kernel release cycle could be sped up. The situation feels very similar to two years ago, when everybody was wondering where the 2.2 kernel was. 2.6 will probably be the same.

Alan Cox did post an interesting suggestion. In his scheme, there would essentially be two stable kernel release tracks. Once 2.4 comes out, the 2.5 development series would go off as usual. At some point, however, the developers would stop and decide which of the new features could be backported to the 2.4 kernel in a stable manner. That port would be done, with the result being 2.6. The 2.5 series would then be renamed 2.7, and the whole thing would eventually be stabilized as 2.8.

The idea would be to get a lot of the interesting new features out more quickly, while allowing the deeper changes to mature over a longer period of time.

Doing all of that backporting sounds like a lot of work, but the simple fact is that it happens now. Much of what has gone into recent 2.2 releases has been brought back from the current development series. It could well make more sense to create a new stable series to accept the backports; that way the current stable series could truly be maintained in a bugfix-only mode, which would help it to remain stable.

Jeff Merkey, instead, proposes that the kernel go to a much more modular architecture. Then the core kernel could be released independent of what is happening with, say, the device drivers. This mode of development might well lead to faster release cycles, but it would also require the kernel developers to freeze the interfaces between modules in a much more formal way. The developers have fiercely defended their ability to change the internal API as needed during development cycles. The alternative is to be slowly buried in backwards compatibility cruft. An example would be the block driver interface, which is showing some age and is likely to be severely thrashed in 2.5. An attempt to freeze the internal interfaces in a stronger way would block that sort of change and is likely to meet a high degree of resistance.

It may well be, in the end, that it really takes two years to do a proper development cycle on the kernel. If that proves to be the case, the best thing to do might be to find a way to get the important changes (such as device support) back to the users quickly while giving the deeper changes the time they need to mature and stabilize properly.

Network drivers and randomness. The Linux kernel includes a random number generator. It is used for a number of tasks, mostly security related, both inside and outside the kernel. As anybody who has studied the topic knows, generating random numbers with software can be very hard. Software, being deterministic, will tend to produce predictable numbers. So the kernel looks to other sources for its randomness. Much of this randomness ("entropy") comes from device drivers and their interrupts. The timing of interrupts from the keyboard, disk drives, and so on is variable enough to make the random numbers truly random.

Oliver M. Bolzer was looking at the code to convince himself of its strength and noticed that few drivers participate in the creation of entropy for the random number generator. In particular, he asked, why don't the network drivers take part in the entropy generation process?

It's a good question. After all, packet arrival times will certainly exhibit a certain kind of randomness. The problem is that the arrival of packets is also under external control. A suitably determined attacker could conceivably aim packets at the system in a way that would subvert the random number generator and weaken the security of the system as a whole. It would be a most difficult attack, no script kiddies need apply. But, rather than leave a potential opening in a crucial part of the system, the kernel developers are likely to keep the network drivers out of the entropy business.

On kernels and compilers. Occasionally a Red Hat 7 user, or somebody else with a too-new version of gcc, runs into trouble when compiling the kernel. It's worth remembering that the kernel has a well-defined set of compilers that it is supported with; for 2.2 and 2.4 both it's either gcc-2.7.2.* or egcs-1.1.2.

For this reason, distributions which include newer compilers also provide a special "kernel gcc" package, often called kgcc. It's important to install and use that version of the compiler for building kernels.

The problem here is almost never with the compiler itself. The kernel code uses no end of tricks for performance reasons, and operates in a much more volatile environment than most applications. Successive versions of the compiler tend to be more aggressive and better at optimization; every now and then a new optimization breaks some kernel code, leading to very strange bugs. Over time these get ironed out and the newer compiler becomes "certified" for use with the kernel. Until that time, the only people who should be using newer compilers to build the kernel are those who actively want to find the problems.

The hunt for undefined code. Here's one kind of problem that a new compiler can turn up. Most C programmers learn early on to avoid code like:

	a[i] = i++;

Bernd Schmidt looked through the kernel source for this sort of code, and found quite a bit of it. He has submitted a patch to fix up the things he encountered; as he puts it, "in some cases, it wasn't entirely clear what the code intended, so I had to guess." This patch went into 2.4.0-test10-pre4, so we may well find a spot or two where he guessed wrong. The effort is a good one, though. This kind of code is a time bomb waiting to go off; it needs to be cleaned up sooner rather than later.

Other patches and updates released this week include:

• Jeff Garzik posted a new Via audio driver for 2.4 kernels.

• Ben Greear has released version 0.0.13 of his 802.1Q VLAN implementation.

• IBM has announced version 1.1 of its "dynamic probes" kernel debugging tools.

• Version 0.6.8 of the access control list patch was released by Andreas Gruenbacher. The ACL code is rapidly heading toward the 0.7 stable release, and testers are being sought.

• Rusty Russell has released version 1.1.2 of the iptables utility.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap 2.5 Status

Other resources: L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions