![[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 Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel is 2.5.14, released on May 6. This release includes the usual IDE reworking, a big Bluetooth update, an NTFS update, and a bunch of VM/buffer management work. As Linus points out, many of the changes in this kernel affect fundamental layers of the VM and buffer management subsystems; "backups are always a good idea." There have been few complaints, however. The buffer management changes, which have been working their way in over the last few development kernel releases, make substantial progress toward the goal of eliminating the buffer cache as such. The "buffer head" data structure, increasingly, is used for I/O management and little else. With the recent patches (by Andrew Morton), writeback of dirty I/O pages is done directly out of the page cache, rather than by scanning a list of buffer heads. In a subtle (but important) change, page writeback is now done without locking the page, allowing certain other concurrent uses and reducing lock contention. The change improves performance, but requires kernel developers to be aware that an unlocked page could have write I/O operations active on it. Other changes include hashed wait queues for buffer heads (saving a chunk of memory) and a new way of handling readahead values, which eliminates another ugly global array from the block layer. The latest prepatch from Dave Jones is 2.5.14-dj2, which adds a reworking of the x86 initialization code and a relatively small set of other patches. The latest 2.5 Status Summary from Guillaume Boissiere is dated May 7. The current stable kernel release is 2.4.18. After a long pause, a new 2.4.19 prepatch (2.4.19-pre8) came out on May 2. Marcelo says that there will be just one more prepatch before the first 2.4.19 release candidate. -pre8 includes a big m68k update, many patches from the -ac series, and lots of other fixes. Alan Cox has released 2.4.19-pre8-ac1, which merges with -pre8 but adds no other changes. The end of /proc/ide. The week would not be complete without some discontent over Martin Dalecki's IDE changes. The problematic change this time around was his IDE 57 patch, which removes the code implementing /proc/ide. This directory, and those beneath it, provide a wealth of information about the IDE drives on the system: their geometry, how they are configured, etc. Martin has a couple of complaints about how /proc/ide works. The most important of those is that changing drive settings requires a fair amount of attention to return values, error handling, etc. which "is very unlikely to be implemented in bash." The ability to tweak drive settings should be limited to "real" programs using the ioctl() interface. The other complaint is, simply, that the /proc/ide code is large, about 34KB. The thing is, of course, that some people like to have the information available in /proc/ide. Some of that information can be obtained from the hdparm command, but not all of it. Until somebody steps in and fills the gap, it is going to be harder to look into the IDE subsystem. While some people complain about the continual flux and removal of features in the IDE subsystem, Linus thinks it's a good thing: Who cares? Have you found _anything_ that Martin removed that was at all worthwhile? I sure haven't.
So the IDE reworking process is likely to continue. Is kbuild 2.5 really ready for inclusion? LWN recently stated that, with the solving of the kbuild 2.5 performance problems, detractors were going to have to find some other reason to keep the new system out of the kernel. Well, it seems they have been trying. The big complaint now is that modversions does not work in kbuild 2.5. Modversions, of course, is a mechanism which attempts to make binary modules loadable into multiple kernel versions without recompilation; it is much appreciated by distributors, binary software vendors, and users who like to be able to upgrade kernels without having to rebuild their external modules. Essentially, modversions works as follows. A utility program shipped with the kernel (genksyms) is run as part of the kernel build process. It looks at every interface exported by the kernel, and calculates a checksum based on the types used in that interface. Thus, for example, it may look at the prototype for kmalloc(): void *kmalloc (size_t size, int flags);From the name, the void * return type, and the types of the arguments it generates (say) a checksum of 93d4cfe6. Through a bit of a long process, any module which is compiled for this kernel will include a definition (essentially) like: #define kmalloc kmalloc_R93d4cfe6The module will thus expect to link against the mangled version of the name, not straight kmalloc. The mangled names are not used for hard linking within the kernel. They do, however, find their way into the kernel symbol table (and can thus be seen in /proc/ksyms). When insmod is used to load a module, it checks the mangled names against the symbol table, and will only load the module if they match. Thus, if the interface to some function has changed, the insert will fail and the module will have to be recompiled. In practice, it doesn't always work quite that well. genksyms can find interface changes, but it is unaware of numerous other changes which can make a module unsuitable for insertion into any given kernel. One of these issues (SMP versus uniprocessor) is handled in the kernel makefiles, since it is a common and devastating case. But other options - preemptable kernel, memory model, etc. - are not caught, and can result in the loading of a module which brings down the system. There are also scenarios where modversions can fail to catch an interface change if the user is not careful. Kernel developers themselves rarely turn on modversions; it does not normally help them, adds extra processing, and it has a hackish feel that turns people off. So it is surprising to see complaints about modversions not working in kbuild 2.5, especially since kbuild developer Keith Owens has said that he plans to fix it once kbuild is part of the mainline kernel. In fact, he plans to fix it right, using the same emphasis on getting the right result that he has applied to the rest of the kbuild system. So modversions will be back for the next stable series, which is the only time it really matters. SELinux as a Linux Security Module. The NSA's Security Enhanced Linux is one of the better-known high-security Linux distributions. SELinux was also one of the first demonstrations of a security structure built upon the Linux Security Module (LSM) patch. The SELinux hackers have now posted a report describing how SELinux was implemented over LSM. It's worthwhile reading for anybody who is interested in how the LSM patch works, or in how a high-security system can be built over the Linux kernel. Other patches and updates released this week include:
Kernel trees:
Core kernel code:
Development tools:
Device drivers
Filesystems:
Kernel building:
Miscellaneous:
Networking:
Section Editor: Jonathan Corbet |
May 9, 2002
| ||
Copyright © 2002
Eklektix, Inc., all rights reserved
Next: Distributions