Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Linux History Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current kernel release is still 2.4.14. Linus's prepatch series is up to 2.4.15-pre7. Very little beyond basic bugfixes has been added to the prepatch in the last week; it appears to be stabilizing. The 2.4.15 kernel may have been released by the time you read this. Where are the "ac" patches? One user asked when Alan Cox would resume making patches that tracked the 2.4.15-pre Linus tree. The answer would appear to be "not anytime soon." Quoted in full: Right now I've fed all the stuff I feel makes sense to Linus for 2.4.15. Once 2.4.15 is out I'll send some more bits to Marcelo, and also some bits to Linus that are 2.5 material (eg PnPBIOS). The only "-ac" patch as such would be for 32bit quota and other oddments so I don't think its worth the effort. Among such "oddments," of course, is the virtual memory implementation that the "ac" series has been using... How synchronous should Linux be? One day, as Andrew Morton was wandering around the filesystem code, he noticed a seeming inconsistency. While Linux, like most operating systems that are concerned with performance, buffers filesystem writes in the kernels, it does provide a couple of ways for the user to request synchronous behavior:
It turns out, though, that there are two types of opinion regarding synchronous writes of file data. Linux has never, in the past, had that behavior. The claim in the mount man page ("All I/O to the file system should be done synchronously.") is simply incorrect. Fully synchronous behavior is very expensive, leading to horrible performance, and is, according to some, rarely needed. It is better, according to this camp, to expect applications to use the fsync() system call to explicitly force synchronous behavior when it's needed in a specific situation. Rather than implement synchronous file writes, these folks (as typified by Stephen Tweedie) propose instead to limit implicit synchronous behavior to directories. On the other side, Jeff Garzik argued that implementing synchronous file writes is the correct thing to do. Users sometimes need that behavior, and it is impractical to hack up applications and scripts to call fsync() explicitly. A separate dirsync mount option could provided to request synchronous semantics for directories only. Amusingly, Andrew appears to have been won over by the first point of view, but his patch (implementing the second) found its way into 2.4.15-pre5. Unless something changes, fully synchronous behavior will be the way of things in 2.4.15. Proposed feature: devlinks. Access to and naming of devices looks like it could be one of the truly divisive issues in 2.5 kernel development. The current system (static nodes in /dev using device numbers) is showing a few signs of strain:
One solution to all of these problems, of course, is devfs, which is included in the 2.4 kernel. devfs is still not widely used, for a number of reasons. Its use requires non-trivial configuration changes, and the code contains some race conditions and locking bugs that are only now being sorted out. Its use also changes the way policy issues (device names and access permissions) are handled. The kernel can not remember (or guess) the permissions required for a particular device on a given system. This problem is handled with a user-space daemon, but not everybody likes that solution. Neil Brown has come up with an interesting way of dealing with some of those issues. His proposal, implementing a feature called "devlinks," puts a static administrative layer in front of devfs, allowing a system administrator to set up system-specific policy while using devfs to get away from device numbers. A devlink is essentially a new entry point into the devfs filesystem. The mechanism is a little clunky at the moment: the administrator creates a normal symbolic link, then types a magic mknod command that mutates it into a devlink. The devlink then acts as an access point to the devfs device. The crucial point, perhaps, is that the devfs filesystem itself need not be mounted. If devfs is left unmounted, devlinks become the only access path to the device. As such, they can be used to set permissions and device naming policy. And, since they are stored in a normal filesystem, they are persistent. The devlink proposal does little for the handling of dynamic devices, and a directory full of devlinks could become just as cluttered as the current /dev. The proposal seems unlikely to get into the 2.5 kernel in its current form. But, as an attempt to work toward a solution to the device naming problems facing Linux, it is an interesting beginning. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
November 22, 2001
| ||