[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


The current development kernel release is 2.3.12. There is a 2.3.13 pre-patch available. In this patch, Linus has changed the way driver initialization is done, eliminating the need for the big pile of ugly #ifdef's in init/main.c. This is a far-reaching change, requiring tweaks in lots of drivers. There is nothing complicated about these tweaks, but there are a lot of them, so it could be a little while before this change works it way through all the code. See Linus's announcement for a bit more information.

Linus has also proclaimed that a 2.3 feature freeze will probably happen in about two weeks. He is clearly serious about trying to get a 2.4 out in the fall. While there is little disagreement that 2.2 was too long in coming, one could well wonder if 2.4 isn't being a little rushed. By some accounts, 2.2 hasn't really stabilized yet (though it works great for most people); by the time it does, it may already be obsolete.

Looking forward to 2.4, Joseph Pranevich has put out the first version of The Wonderful World of Linux 2.4, which describes the changes that will appear in that release.

The current stable release remains 2.2.10. Alan Cox has been passing around a set of 2.2.11 pre-patches, but Alan has been somewhat scarce in recent weeks and progress on that front has been slow.

If there are any Sparc users who are considering trying 2.3, our advice is to wait. Some of the memory management changes in 2.3 broke badly on the Sparc, with the result that the 2.3 kernels do not build. Work is underway to fix that, but it's going to take a little while yet. Unless you're willing to help out with the work, the best thing to do is to hold off for a few more releases.

Your backup is unsafe, but don't worry too much, it's just a Windows partition. So starts this note from Robert de Bath. Here's the problem: those who have dealt with the Windows "VFAT" file system know that there can actually be two names for a file. The file system supports long file names almost like a real operating system, but, underneath it all, there is a DOS 8.3 ("short") filename that really identifies the file. Thus "Program Files" becomes "Progra~1".

The Linux VFAT file system only makes the long file name visible to the user, on the reasonable assumption that it is the one they want to see. Usually all works just fine. But imagine that you back up this file system, then restore it at some future time. All of the long file names will go back the way they were before, but Linux has to generate new 8.3 names to go with them. Those 8.3 names will usually be the same ones that were there before, but not always.

Changing 8.3 names would not necessarily be a problem, if it weren't for certain programs (i.e. Office) which actually depend on them. Long and short file names also tend to get mixed up in the Windows registry, leading to serious havoc if they do not continue to match up together. Since there is no reason why a rational person would use VFAT if they were not working with windows software, this is a real issue.

Solutions to this one will not come easily. The Unix worldview is just not prepared to deal with two weirdly linked names for the same file in this manner. The most common idea was to turn the long file name into a link (either hard or soft) to the 8.3 file name, and present both in a directory listing. Since VFAT does not support links, this usage would be unambiguous, and seems like an easy way out.

But only until one really thinks about the problem. The short and long names are tied much more tightly than Unix links; who expects that, when you rename one link to a file, that the other would change too? Since directories, too, have long names, the use of hard links is out of the question; hard links to directories are a quick path to trouble in almost any Unix-like system. Even with symbolic links, trying to make everything actually work right would be slightly less fun than, say, being tied over an anthill.

So it's not clear that this problem will get solved. And one could indeed ask how important that is; it seems that almost all backup programs that run under Windows have the same problem. VFAT, in the end, is a piece of ugliness that is exceptional even in the Windows context; there is only so much that can be done to make it work right.

A few notes on SCHED_IDLE, the proposed new scheduler class (discussed in last week's issue) which would run low-priority cranker jobs only when nothing else wants to run:

  • Rik van Riel noted that the patch has progressed since the version we published last week; see his kernel patches page for the current version.

  • Artur Skawina posted a competing implementation which, according to him, works much better and imposes no costs on the normal (non-SCHED_IDLE) case.

  • Victor Yodaiken, who fears the numerous deadlock and performance problems that SCHED_IDLE can bring, posted this note on alternative ways to deal with the problem. It is simultaneously humorous and convincing, worth a read.

Other patches and updates released this week include:

  • Jens Axboe has set up a web page for Linux CD and DVD development. Information on CD-RW and DVD developments can be found there, and the current patches can be downloaded.

  • Yann Droneaud posted a version of the boot code that has been rewritten for the gas assembler. Nobody much likes the as86 assembler currently used for this code, but there is not a whole lot of sentiment in favor of gas either. There is a third assembler (nasm) which seems to have more appeal; if as86 goes away, it may be nasm that takes over. (See also: the posting and, for the really curious, the new boot code).

  • Etienne Lorrain posted an announcement for a new bootloader, which competes with programs like LILO. This one is different, however, in that it does not (yet) work...

  • Rolf Fokkens posted a patch allowing the user some control over the mapping between SCSI devices and their names in /dev. Currently, adding or removing a device on a SCSI chain can cause all of the others to be renamed, leading to much tearing of hair among the system administration staff. This patch seems like a simple solution to the problem for admins who know that they will be making hardware changes.

Section Editor: Jon Corbet


August 5, 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