See also: last week's Kernel page.

Kernel development

Stable kernel 2.2.13 still has not been released, but we are getting closer. Alan Cox has released 2.2.13pre17which contains some last-minute fixes. If all is well after a week of testing, it will go off to Linus.

Full scale devfs flame war continues to rage in linux-kernel. Most of the discussion is not particularly rewarding to read, but at the base of it all there are, in fact, some real problems with Linux device management that need to be addressed. These include:

• Devices are increasingly dynamic. They can come and go at the user's whim, and they can reappear in different places each time. The old Unix device model assumes that things do not move around; thus the static set of device nodes in /dev that (normally) do not change.

• The major/minor device number space is being exhausted. Major numbers, remember, correspond to device drivers; minor numbers are interpreted by the drivers themselves and usually correspond in some way to physical devices. Linux currently only allows eight bits each for the major and minor numbers.

  The device number space has already been strained by systems running large numbers of SCSI disks. USB systems can conceivably (and realistically) have hundreds of identical devices. The device numbers simply do not exist to support that sort of configuration.

• /dev is a cluttered mess. Most distributions ship /dev with every device node that the system might have to use. The result is often 2000 entries or more, almost all of which correspond to no devices actually present on the system. In the future, as the number of possible devices explodes, the size of /dev can be expected to increase tremendously.

  A device directory that large presents a number of management problems. There is also a large set of users who find it simply annoying; they want to see in /dev only devices which actually exist on their computers.

Devfs opponents claim that it is the wrong solution to the problem. It tries to solve several problems at once, instead of attacking each one separately. The way devfs handles persistence of device permissions (by running tar at shutdown time) bothers some people. Many see the kernel space filesystem as being unnecessary. Some have criticised how it interfaces with the Linux VFS layer, suggesting that it will create problems in the future.

Regardless of one's individual opinion on devfs, it seems unlikely to get into 2.4 at this point. The feature freeze is in effect, and there is simply too much opposition to it.

So how will the problems get solved? This discussion began, a while back, as an attempt to figure out how to handle numbering for USB devices. That problem has to be solved for 2.4 if that kernel is to ship with a working USB implementation. The following is speculation, based on a reading of the debate and a general sense of how the wind is blowing:

• Device numbers will go from 16 to 32 bits, with perhaps ten bits for the major number, and 22 for the minor number. Making the device type any larger than 32 bits invites problems with NFS. On the user space side, this change should be relatively easy - glibc has been using a 64-bit device type for a while. But it is still a big change, and probably will not happen for 2.4.

• There appears to be consensus that some sort of user-space daemon process is required to perform dynamic device management. Devfs provides one such daemon, but many people think it can happen without the devfs kernel code. All that is really needed is a mechanism by which a user-space process can be informed when the system's hardware configuration changes. The process can then play with device nodes, and implement whatever local policy (device permissions, names, processes to start, modules to load, etc.) that the administrators have set up. This sort of "devd" (H. Peter Anvin's term) process would be a relatively lightweight and flexible solution to the problem.

• One or more major device numbers will be assigned to USB devices in general. Minor numbers will be handed out dynamically in response to USB events, with the user space daemon process expected to create and remove actual device files in response.

(See also: the devfs FAQ). Also, in the middle of all this, Richard Gooch released devfs v123.

knfsd patches. H.J. Lu has been making a lot of changes with his more recent patches to the kernel NFS server. The result has been a temporary loss of stability. Thus, H.J. cautions that version 1.4.7 of his NFS patch should be regarded as the production version; the 1.5.x versions are developmental.

Clarification on recent TCP vulnerabilities. There was a fair amount of confusion last week over just where the vulnerabilities in the TCP stack lay, whether predictable IP ident numbers were a vulnerability, and so on. LWN got more confused than many, unfortunately. Paul Rusty Russell sent in this note clarifying the problems with the TCP stack, for which we thank him. Meanwhile Andrey Savochkin has come to the conclusion that predictable IP idents are not as big a problem as he had thought...

Other patches and updates released this week include:

• PPSkit 0.8.0 by Ulrich Windl.

• Keith Owens released several versions of the modutils package, culminating in modutils-2.3.5. Among other things, these releases change the default configuration file to /etc/modules.conf, but will read the old conf.modules files (with a complaint) for some time.

• Trond Myklebust announced a port of the NFSv3 client implementation to 2.3.21.

Section Editor: Jon Corbet

For other kernel news, see: Kernelnotes Kernel traffic Kernel Newsflash

Next: Distributions