Sections:
Main page
Linux in the news
Security
Kernel
Distributions
Ports
Development
Commerce
Announcements
Back page
All in one big page

Kernel development

The current development kernel release is 2.1.126. This release (announcement here) had a number of compilation and lockup problems, and is probably best avoided. For those wanting to be on the bleeding edge, 2.1.127 prepatch 3 is available. It fixes some of the other problems, includes a lot of Sparc fixes, memory management fixes, SCSI fixes, and other, well, fixes. At least some of the kernel NFS fixes appear to have gone in as well.

Of course, 2.1.127 may well be out by the time you read this.

Whither 2.0.36? It has now been some time since a couple of "release candidate" pre-patches went by. At the last minute a few problems turned up, so Alan Cox called off the release for the time being. Those problems are being fixed, and a new release candidate pre-patch should show up before too long. At that point, it has to go (again) to Linus, who will then decide whether it goes out as is or whether changes need to be made. So the real 2.0.36 release is probably a bit distant still.

Richard Gooch continues to press forward his devfs patch; it is currently up to release 74. Still no official word on inclusion in 2.2 from Linus; at this late date it could well be that the chances are fading.

What is the best way to export kernel information to user space? This discussion evolved out of the "jiffies" debate (see last week's issue). Currently there are a few ways of getting pieces of system information from the kernel:

The sysctl() system call,
information-specific system calls (i.e. getpagesize()), and
from "files" in /proc.

There is a fair amount of disagreement over what is the right approach; there is also quite a bit of inconsistency currently in how things are implemented. Not only are three different methods used, but /proc suffers from consistency and portability problems of its own.

At this stage in kernel development (i.e. code freeze) major changes are not going to happen. But that doesn't stop people from talking. Linus seems to favor adding new system calls; other kernel developers seem to prefer sysctl. Others like /proc (everybody seems to think /proc is needed for some information), but some folks still evidently run systems with /proc disabled.

There was some talk of trying to rationalize the contents of /proc. Currently data appears in different formats in different places, and, occasionally, it is dependent on the underlying architecture of the host system. The problem there is that if, for example, /proc is exported via NFS from a little-endian system to a big-endian system, the latter will not be able to make sense of what it sees.

The position taken by Linus, and readily agreed to by most, was that information in /proc should be formatted in unambiguous ways. IP addresses, for example, should be in the "dotted quad" notation. This sort of rule, consistently applied, could clear up a lot of problems. There was even a patch posted to clean up some of the files in /proc/net. Of course, (1) there is a code freeze in effect, and (2) actually changing the format of /proc files breaks all of the applications which use them. So it is not clear how far that patch will go.

A new version of ksymoops has been posted. Ksymoops, of course, is a little program which takes the output from a dying kernel and turns it into a symbolic form which can be interpreted by others. Here's the announcement for those who are interested.

October 29, 1998

Since we're a weekly publication, chances are we'll be behind a rev or two on the kernel release by the time you read this page. Up-to-the-second information can always be found at LinuxHQ.

Next: Distributions