Patches continue to accumulate, slowly, in Linus's BitKeeper repository. These include the un-deprecation of MODULE_PARM() (it is generating too many warnings, and the fixes will not be merged before 2.6.10), a new major number (180) for the "ub" USB storage driver, some x86 single-stepping fixes, a large number of "sparse" annotations, the token-based memory management fix, a memory technology device (and JFFS2) update, a frame buffer device update, some user-mode Linux patches, some page allocator tuning, and a few architecture updates.
The latest patch from Andrew Morton is 2.6.10-rc2-mm4. Recent changes to -mm include a new "DMA32" memory zone on the x86_64 architecture, some big architecture updates, a quiet fix for a seemingly exploitable x86_64 buffer overflow, and lots of fixes.
The current 2.4 prepatch is 2.4.29-pre1, which was released by Marcelo on November 25. The bulk of this patch consists of driver and filesystem backports from 2.6.
Kernel development news
But we never forgot the request. Of course, it helps that certain readers regularly remind us... Starting this week, we have a tentative solution. The Gmane archive makes it easy to read through archived lists and create URLs to them. Thanks to a bit of script hacking, many of the quoted messaged linked to in this page now have an Archive-link header pointing to the Gmane version of the message, and to Gmane's thread view as well.
This feature should be considered experimental for now; whether it is retained depends on whether readers find it useful, and whether Gmane proves to be sufficiently reliable over time. We're curious to hear whether these links are worthwhile. With luck, an ancient item can now be scratched off the "to do" list.
Unfortunately, things do not always work that way, and some user-space programs still end up including kernel headers directly. These programs may simply be old, or they may need access to declarations which are not available in the C library include files - strange ioctl() codes, for example. So the kernel code still tries to make it possible for user space to include some header files. In these files, kernel-specific code is contained within #ifdef __KERNEL__ blocks and hidden from user space. This technique works, but it is brittle and adds extra cruft to the kernel code base. Intermixing internal kernel definitions with those needed by user space also makes it easy to break the user-space API.
The kernel developers have, for years, wanted to improve this situation. The latest attempt came in the form of this RFC from David Howells. This proposal would create some new directories in the kernel source tree: include/user and some architecture-specific variations (such as include/user-i386). When a portion of a kernel header file is found to be needed by user space, it would be placed into a separate file in one of those directories, and the new file would be included into the old one. At this point, the definitions needed by user space will have been separated out, but no visible changes will have been made; user space can still include the old file and get what it needs.
At some future point, when user space is deemed to have been fixed, all of the __KERNEL__ references could be removed from the old files. At that point, any application still including the internal header files would break.
One part of the idea which did not get very far was using standard C types (such as uint16_t and such) for the user-kernel interface. The problem with that idea is that the kernel cannot count on those types being consistently defined for all configurations, and cannot create its own definitions for the standard types. So the kernel/user interface must continue to be defined using kernel-specific types (__u16 and such).
Linus was not all that enthusiastic about the idea in general. To him, it looks like an exercise in rearranging things without specific goals and with the possibility of breaking things which work now:
What he would like to see is more specific discussions which identify specific, problematic header files and what will be done to fix them. In the end, the header files might just get split up in the way described by Mr. Howells. It is more likely to happen as a long and slow process, however, and not as a massive, coordinated reorganization.swsusp2 implementation has come a long way. Still, two implementations of a low-level core function seems like too many, so there is interest in bringing them together in the mainline. Swsusp2 developer Nigel Cunningham has made a new effort in that direction by posting a set of 51 patches which merge swsusp2 into the 2.6 kernel.
There is a great deal of code in these patches. Some of the more interesting pieces include:
The swsusp2 code wants these symbols exported because the entire suspend mechanism can be built as a module and loaded only when the system is to be suspended. This can be a nice feature; swsusp2 is a lot of code, and it is all excess baggage anytime the system is actually being used. The costs of making swsusp2 modular may prove too high for that feature to be accepted into the mainline, however.
Nigel offers a number of reasons for merging swsusp2. It is claimed to be much faster as a result of the use of asynchronous I/O, readahead on resume, and (for systems with slow drives) image compression. It is far more configurable; users can select the sort of display they like, image compression and/or encryption, etc. Suspending to swap files, LVM devices, and more is supported. And so on. There is little disagreement that swsusp2 offers some nice features, but there is some concern over how Nigel is trying to proceed:
The kernel developers are increasingly resistant to wholesale merging of large blocks of code - especially when that code duplicates functionality already found in the kernel. They would rather see a series of incremental patches, each of which takes a small, useful step in the right direction. Nigel does not want to do that; swsusp2 is vastly different, internally, than the mainline suspend code, and evolving one into the other looks like a long, painful, and pointless job. He may have to do that work, however, before any of the swsusp2 code can be merged.
A bigger obstacle, however, may be the fact that, while swsusp2 was being developed, the mainline software suspend code was progressing too. Your editor is able to reliably suspend to memory and disk with a vanilla 2.6.9 kernel. SUSE enables software suspend and calls it a feature in its 9.2 release. Since the in-kernel suspend code seems to actually work, enthusiasm for replacing it with a larger, more complex version is not as high as it might otherwise have been. The ultimate fate of swsusp2 may yet be to contribute its best improvements to the mainline, but to never be merged in its entirety..
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds