See also: last week's Kernel page.

Kernel development

In fact, Linus announced that he had no plans to release even a 2.2.1 kernel for "several weeks." Alas, he said that just before reading this note announcing the discovery of the "ldd core" bug. Essentially, if you run "ldd core" on a stock 2.2.0 kernel, you will find yourself in "fsck the disks" mode in a hurry.

The response to this bug was a classic example of Linux parallel debugging. Reports flew back and forth as people closed in on the problem; the culmination was this patch from Ingo Molnar which closes up the hole. (Ingo also posted a minimal exploit program showing the operation that actually caused the crash). The total elapsed time was about nine hours. No proprietary system can ever match that sort of bugfix performance.

As a result of all this, a 2.2.1 release is quite likely within the next few days.

Alan Cox announced that the "-ac" patch series is done for now, then promptly put out 2.2.0ac1, which contains a number of fixes that didn't squeak into the 2.2.0 release, then 2.2.0ac2 with more fixes, including the "ldd core" crash fix.

Some resources for people upgrading to 2.2, since there have been reports of problems. You need current versions of a number of utilities, including networking and PPP. The changes file on LinuxHQ gives a list of the various software versions you need to have to run 2.2 successfully. Do give it a look before upgrading, and certainly before complaining about something that does not work. See also Alan Cox's 'Clue-point-two' document for answers to some frequently asked questions. Finally, Joseph Pranevich has put out the "absolutely final version" of his Wonderful World of Linux 2.2 document, which is a great overview of the changes in 2.2.

If you want to build 2.2.0 on a Sparc system, you should obtain and apply the Sparc patch posted by David Miller.

The memory management issue refuses to go away even though 2.2.0 is now out. There are some grumblings within the ranks of kernel developers. Some of the outstanding issues include:

• Systems with more than 2GB of memory are not easily supportable under Linux. This discussion did not get very far before Linus simply squashed it. His position is that people who want to run that much memory should do so on a 64-bit system. "This is not negotiable."

• Allocation of large (4MB) physically contiguous memory areas in the kernel. The sad fact is that there are increasing numbers of peripherals, such as sound cards and frame grabbers, which require this sort of allocation. Solutions to this problem seem to involve some sort of complicated shuffling of data structures in memory, not for the faint of heart. An attempt to make it work in 2.3 is likely.

• General interactive response. There are complaints that the 2.2 kernels are far worse than the late 2.1 kernels in terms of response under load. See, for example, this note from Stephen Tweedie. There is, it would seem, a need for more tweaking in this area, if not for some more major work (such as adding the ability to swap out page tables).

Numerous people hunted a problem with the Netscape browser, wherein it would freeze at inopportune times. Many suspected a kernel bug, but the problem turns out to be in Netscape's court. If you're having these sorts of difficulties, consider using this hackposted by Stanislav Meduna. The code has its own problems (see this note from the author), so it should not be used without need. But people with browser difficulties may find some relief here.

Linux-kernel mail on vger backed up yet again, leading to another disabling of anonymous CVS access on that system. "Fear not," says David Miller; another system is coming in to host the anonymous CVS function.

More resource limitations: the bandwidth upgrade for kernel.org has been delayed again, for at least a couple more months. As a result, kernel.org will remain difficult to get into for a while; people looking for kernels should just use the mirror sites.

Version 5.0.1 of the Coda filesystem has been released, see the announcement for more. This is a bugfix release.

The "Kernel Traffic" site has moved and adopted a new format as well. Check them out at the new site.

Another four-letter word in the kernel. Some of you may remember the article in our October 15 kernel section, wherein somebody had grepped through the kernel source for their favorite vulgar word and found many matches. It's hard not to draw a parallel between that exercise and this message from Dave Jones. Dave went looking for a different offensive word, and was "shocked" to find almost 1,000 goto's in the kernel source. Certainly this code is insufficiently structured for sophisticated company! "The use of constructs such as goto are outdated crutches used by people too lazy to write a more structured solution." As may be expected, a bit of discussion resulted from this posting, mostly defending the use of goto in particular situations. In any case, the odds of Linus accepting a large un-gotoing patch are probably small...

Since we're a weekly publication, chances are we'll be behind a rev or two on the kernel release by the time you read this page. Up-to-the-second information can always be found at LinuxHQ.

Next: Distributions