[LWN Logo]
[LWN.net]

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

See also: last week's Kernel page.

Kernel development


Kernel version 2.2.4 has been released. Last week, we optimistically theorized that the 2.2.X kernel series was stabilizing rapidly. The 2.2.4 release, announced by Linus, somewhat dampened that optimism. Compilation problems were quickly found in the new kernel, in the BSD process accounting code. A patch was quickly made available for that, but another problem was found for people who enable Kernel/User netlink socket, Routing messages, and Netlink device emulation, but don't enable Ingres traffic policing. Patches for both of these problems can be found on Robert Gooch's new page, which will be used to track known problems with patches available for the latest kernel.

In addition to the compilation problem, there have been a large number of reported oopses for this most recent kernel. These include two reports of "put__dirty_page: page already exists" errors in syslog during compilations (reproducible in 2.2.3 as well), and a potential problem under certain load conditions. Linus generated a one-line testpatch for the latter, which he has asked people to check out to see if it makes any difference. Apparently the circumstances that might generate the load problem would be fairly pathological, and therefore highly unlikely to occur, at least in theory.

Last, there are some oopses occurring that may be caused by a bug in egcs, or at least triggered by a difference in behavior between egcs and gcc-2.7.2 (or possibly not). As demonstrated in this note from Linus, tests on this problem are at too early a stage to be able to actually point a finger.

In the Alan Cox tree, 2.2.3ac3 and 2.2.3ac4 were both announced this week. Presumably 2.2.4ac1 will be out shortly.

Meanwhile, the longest running discussion of the week focused on file system performance. Starting with this note from Yasushi Saito about disk head scheduling, the thread broke into several lengthy discussions. The first thread focused on whether or not optimizing for disk architecture was worth doing. The answer, in the end, is no, because modern devices do not accurately provide the physical layout of the disk. As Linus stated, " Quite frankly, anybody who even _thinks_ he knows how the disk is organized is living in the past. Give up on it, and just consider it a linear array of sectors. In addition, any potential performance improvement would be offset by the disadvantages of the added complexity of the code.

This discussion, however, spawned a new one on the kernel IO-request queue. Many people assume that the kernel IO-request queue is a single queue. Linus retorted emphatically that it is not, blaming the misapprehension on the way the SCSI layer is designed. The conversation then moved to discussing how the SCSI layer should be improved. Work on it has been dropped for quite a long time. It seems like that may change soon. Here is a nice final summary from Gerard Roudier. Lest you think, though, that a unanimous opinion on the problem was reached, this note from Gadi Oxman describes how the current behavior evolved and the advantages of it.

Last, it was suggested that the issues are all moot, since disk drives using static RAM may become actually affordable in a few years. "Disk drives currently under test use static RAM. This is not the Slow........ NVRAM where you write then read-read- read-read, etc., until it finally "takes". This is real static RAM with a 3-volt battery to keep it alive for 20 years," mentioned Richard B. Johnson. Nicholas J. Leon commented that he has built specifications for a RAID system using such technology. 60GB of data for over $50,000 using solid state disks and a fibrechannel backplane ... not affordable quite yet!

For followup information on the above topics, check out this list of publications.

Modutils 2.2.2 is nearing release. Bjorn Ekwall expressed his optimism when he released modutils-2.2.2-pre3 and it is still likely, even though he released modutils-2.2.2-pre4 shortly after pre3. Note that pre4 also requires a small patch.

Discussion of a buffer hash leakage in Chuck Lever's instrumentation patch generated three patches, one from Andrea Arcangeli, one from Chuck Lever himself, and a last patch from Linus. Linus' patch was checked out by Stephen Tweedie and given the thumbs up, at least for now.

CPU Management for Linux was the topic of this posting from Martin Neumann. In this case, cpu management means the ability to handle hot-pluggable CPUs. Martin asked if this was in the works for Linux. Jakub Jelinek and Alan Cox confirmed that it is on the to-do list for the 2.3 series, along with hot-pluggable memory. From the discussion that resulted, no one expected this to be that difficult to add in. Various other patches and utilities released over the last week:

  • Andrea Arcangeli released a patch for a virtual SBPRO 16bit 44.1khz stereo. He also posted some updated versions, of which this was the last one.

  • Andrzej Krzysztofowi posted a new version of his xconfig snapshot.

  • Chuck Lever updated his simple rlimit patch.

  • Gustavo Zacarias posted a patch against 2.2.3 to get ramdisk to take size as a parameter. It seems that otherwise you will always get 4096K ramdisks unless you modify rd.c by hand.

  • Alexander Viro provided a patch for a buglet in ntfs_create() and ntfs_mkdir().

  • Nate Eldredge made available a patch to allow debuggers to change the number of a system call when they trace it. Chris Evans commented that this technique is the same as the one used by the JANUS security system.

  • Version 95 of Richard Gooch's devfs patch is now available and contains a couple of new bug fixes, including another one for the joystick driver.

Section Editor: Jon Corbet

Guest Editor for the Week: Liz Coolbaugh


March 25, 1999

For other kernel news, see:

 

Next: Distributions

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