Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel is 2.3.21. Recent patchs include a
tremendous number of fixes, and a reorganization of the network driver
source tree. No announcements have come with these releases.
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:
Devfs is being put forward by its supporters as a solution to all of the
above problems. It does indeed address all of them. It implements a
dynamic device directory that can change along with the physical
configuration of the system. It does away with major and minor device
numbers, eliminating that problem for the most part (it still crops up in
places). And the devices directory created by devfs contains only devices
which truly exist on the system, and thus lacks clutter.
- 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
- 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:
Such a solution appears workable, and requires little in the way of major
kernel changes. A resolution (for 2.4) along these lines would not be
- 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
- 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
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
October 14, 1999