[LWN Logo]
[LWN.net]

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

See also: last week's Kernel page.

Kernel development


The current development kernel release is still 2.3.99-pre5. This release has drawn a steady stream of complaints about substandard performance and poor memory handling. The kernel developers are still trying to get a handle on where the problems came from.

A prepatch for 2.3.99 is available, and in its third iteration as of this writing. It contains more i386 interrupt handling work, a number of small Sparc tweaks, some large I2O updates, an ISDN update, some sound driver updates, and some ATM networking updates.

Here's Alan Cox's latest 2.3.99 jobs list(from April 16) showing what remains to be done before 2.4 can come out.

The current stable kernel release is forever 2.2.14. The 2.2.15 prepatch got up to its 19th version when, according to Alan Cox's diary, a memory corruption bug was found in the tty drivers. Even though the bug does not appear to be creating troubles for anybody at the moment, the developers still want to get it fixed before putting out the next stable release. Hopefully it won't be long, since 2.2.15 also fixes the recently-found masquerading vulnerability. (Evidently Linus is moving into a new house, which is not helping to get kernel releases out quickly).

So you thought the devfs flamewars would end just because it got into the 2.3 kernel? No such luck, alas... the flames burn as brightly as ever, though in a bit of a different mode.

The hot issue at the moment is how to deal with hot-plug devices, such as PCMCIA, USB, or hot-plug PCI peripherals. In particular, how should these devices be named? This is not a new topic, but it still seems to resist any sort of resolution.

When a new device shows up on the system, the kernel reacts by simply picking the next available device name for it. This behavior is not new either: plugging a new SCSI device into a Linux system has been able to cause a renaming all other SCSI devices on the system for years. There appear to be two types of Linux users out there; the first type finds it really annoying when devices change names, and the second does not seem to care much. One of the purposes behind devfs was to address the frustrations of the first group - it can provide stable names for SCSI devices.

Items on a SCSI bus can be uniquely identified by their bus and SCSI target numbers (OK, unit numbers too, on rare occasion). Devices plugged into a USB hub, however, lack that characteristic. These devices can come and go, and the system can not really track their state in between. So how do you name them in a way that keeps administrators and users sane?

Some think that devfs can help. Some USB devices can provide serial numbers which can be used to create stable names. Disk partitions can have "UUID" identification numbers in their filesystems which can make life easier as well. But if you have two mice and want one to always be /dev/mouse0, life will be difficult. The hardware side of the equation is getting more dynamic, and the software side is finding it harder to simulate stability.

Devfs could maybe provide some of that stability. But users are running into one of the perennial devfs problems: the persistent storage of attributes, such as file ownership and permissions. Devfs can be set up, via devfsd or by simply using tar, to set attributes correctly on stable devices. But that scheme tends to fall down when devices come and go. So people criticize devfs, but better solutions have been somewhat scarce thus far.

Richard Gooch has said, however, that he will be implementing "tunneling" so that devfs can make visible device entries in the underlying /dev filesystem. That change will make persistence somewhat easier, and will also, incidentally, fix the "I configured in devfs and now the system won't boot" trap that is currently so easy to step into. Richard has not given a time frame for this work, but one would assume that he is aiming for the 2.4 kernel. (Richard has, meanwhile, released devfs v162 and devfsd v1.3.5).

Other patches and updates released this week include:

  • Powertweak 0.1.12, a program for digging around in your system's hardware, was released by Dave Jones.

  • For those of you wanting to play with a bleeding-edge PPP driver, Paul Mackerras has released a beta version which includes multilink support.

  • Borislav Deianov has updated his atomicps patch, which provides process information without /proc for memory-limited systems.

  • There is a new reiserfs beta (3.6.4) out there.

  • Mission Critical Linux has released version 3.0 of its kernel core dump facility.

  • Olaf Titz has posted a small patch which makes the kernel's compilation parameters easily available for people compiling modules outside of the kernel source tree. This patch, if adopted, should make life much easier for module developers.

  • Benno Senoner has released the "hdrbench" utility, which benchmarks systems operating as a multitrack recording and playback system.

  • Autofs 4.0 pre7 has been released by Jeremy Fitzhardinge.

Section Editor: Jonathan Corbet


April 20, 2000

For other kernel news, see:

Other resources:

 

Next: Distributions

 
Eklektix, Inc. Linux powered! Copyright © 2000 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds