![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 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, well, actually, there is no development kernel release, and there will not be for some time (see below). Now that 2.4.0 is officially "stable," where is one to look for the bleeding edge? Options include 2.4.1, for which there is one prepatch release as of this writing. It is a very small patch which fixes problems seen by a few users. Those looking for something a little more adventurous will probably be more interested in Alan Cox's 2.4.0-ac5; he says: "Handle with care. I think the fs updates are right but I don't guarantee it." This patch contains an astounding number of fixes, many of which may wait some time before getting into 2.4 proper. The current (other) stable kernel release is 2.2.18. The 2.2.19 prepatch is up to 2.2.19pre7. Alan Cox has announced a new policy for 2.2 updates. From this point on, updates to drivers will only be accepted if the same update is also available for 2.4. The current ancient kernel release is 2.0.39, which was announced on January 9. This release was long in coming, and will probably be the last in the 2.0 series. 2.4.0 is out - now what? There is no shortage of kernel developers (and users) who are ready for the end of the 2.4 feature freeze and the beginning of a new development series. Some patience will yet be required, however; Linus doesn't expect to start accepting patches until well into the (northern hemisphere) Spring. In fact, he doesn't even want to see a whole lot of bugfix patches. This posting went out to describe Linus's approach to 2.4 patches: In short, releasing 2.4.0 does not open up the floor to just about anything. In fact, to some degree it will probably make patches _less_ likely to be accepted than before, at least for a while. I want to be absolutely convinced that the basic 2.4.x infrastructure is solid as a rock before starting to accept more involved patches.
The purpose here is to try to get away from a pattern seen with other stable kernels, where stability actually goes down for the first few minor releases. So, this time around, only the most important stuff will go in. There will also be no development series until 2.4 is truly wrapped up and passed on to another maintainer. Linus expects that, as with previous stable kernels, that will not happen for about four months. Says Linus: "In short, I'm hoping for a fairly boring next few months. The more boring, the better."
Zero-copy networking. Some developers are not content with a boring existence, and have started putting out interesting patches for future development kernels. Perhaps the most interesting is David Miller's zero-copy networking patch, which promises to greatly increase the performance of the Linux networking subsystem - which is already fast. Networking in Linux currently involves, at a minimum, copying all data between the kernel and the user process which produces or consumes it. Copying data takes time, of course; it also can clog up the CPU memory cache with useless data. What the zero-copy patch does is attempt to move network data directly between user-space memory and the network interface whenever possible. Such data never passes through the cache and need not be copied by the processor. This patch is a "proof of concept" release; it is not being proposed for inclusion in its current form. Instead, the idea is to get the peer review process going, see what sort of performance improvements really result, and find the problems. The initial indications are good; according to Ingo Molnar, "We can saturate a gigabit link with TCP traffic, at about 20% CPU usage on a 500 MHz x86 UP system." The implementation itself is a bit controversial, however. To do zero-copy I/O, the kernel must locate and lock the user process's data in physical memory. Stephen Tweedie's "kiobuf" infrastructure was developed to handle this task for the raw block I/O subsystem, but the zero-copy networking patch does not use kiobufs. Instead, the developers chose to implement their own subsystem which handles these tasks. Their reasoning is that the kiobuf structure is far too heavy for the needs of the networking code. Network connections are quick, numerous, and transient; the code that handles them also needs to be light and fast. The networking developers concluded that kiobufs did not meet these needs; so they went off and created something they liked better. In the resulting discussion it turns out that Linus does not like the kiobuf interface: And kiobufs can rot in hell for their design mistakes. Maybe somebody will listen some day and fix them up, and in the meantime they can look at the networking code for an example of how to do it. Given the source, this suggests that the kiobuf interface will likely see some major changes in the 2.5 development series, once it gets going. (Note that there is also an updated zero-copy patch for the 2.4.1pre1 kernel available). Security trouble with ReiserFS? A potential security problem with ReiserFS was reported this week. It seems that a buffer overrun problem exists, sometimes, when a directory with an exceptionally long name is created. Not everybody has been able to reproduce the problem, however. The source of the bug has not been positively identified as of this writing. It appears, however, that it may be in the virtual filesystem code, rather than in ReiserFS itself. A definitive fix is thus not available at this time. Chris Mason has released quick and dirty patches (which simply disable long directory names) for ReiserFS 3.5 and 3.6. Those who are especially worried about this problem may want to apply one or the other of the patches to close the vulnerability for now. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
January 11, 2001
| ||
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Distributions