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 developmentThe 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:
Section Editor: Jonathan Corbet |
April 20, 2000
| ||