|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth. |
Back when SysFS was created, it was hailed as a clean, healthy alternative to ProcFS, while critics cautioned that it represented only a fresh start, with nothing intrinsic that might prevent the same degeneration into chaos as afflicted ProcFS. And now, recent efforts by Greg Kroah-Hartman to reorganize the SysFS tree - even slightly - have been rebuffed due to compatibility issues.
Now it looks as though Greg's proposals are becoming more ambitious. Recently he summarized the problem as, "We need a way to show complex class and class device structures properly in sysfs." The solution as he sees it is to introduce the idea of "subclasses," for example having the sda 1, 2, and 3 subclasses contained within the more general sda class.
The idea is not being met with universal praise. Dmitry Torokhov feels that Greg's proposal neglects some useful needs, such as being able to identify all the input interfaces present on a given system. Dmitry goes off on the opposite tack, suggesting abandoning the entire idea of a class, and grouping SysFS directory entries by function.
Ahmad Reza Cheraghi has created a framework for automatically detecting system hardware and creating a configuration to match. Ahmad's framework does not do the whole job right now, nor is it intended to be maintained by any single person. Rather, it gives driver writers and other folks the ability to maintain their own particular piece of the detection code.
The idea has been welcomed by some and met with skepticism by others. Roman Zippel has said the project is so big it may never be completed. But if successful, it would make it much easier for ordinary humans to compile and use the official kernel.
For awhile now, there has been the growing idea that the vast majority of users will rely on vendor kernels, and that this is how it should be. Linus Torvalds and others have used this as a justification for abandoning the even/odd stable/unstable development system, saying that the official tree can always be in development, while the final stablization efforts can be done by the vendors.
The counter movement against this has been the creation of the w.x.y.z stable series, maintained by Greg Kroah-Hartman, Chris Wright, and others. Ahmad's automatic configuration framework also fits into this counter movement, trying to preserve the idea that the official kernel is not just for kernel developers but for everyone. After all, if regular users don't use the official kernel, then there are that many fewer users producing bug reports for that tree.
Stephen Hemminger and others set up a networking Wiki at http://linux-net.osdl.org and began to add documentation to it. The idea is to centralize networking docs.
Greg Kroah-Hartman asked why not just use an existing Wiki like http://wiki.kernelnewbies.org. Stephen said the kernelnewbies Wiki itself was created when other kernel Wikis were already in existence. He added that he had initially created the networking Wiki for his own use and had generalized it to be something anyone could contribute to.
For 2.6 kernels, OOPS output should no longer be processed through ksymoops before the information is posted to the kernel mailing list. All that is needed now is to enable CONFIG_KALLSYMS when configuring the kernel for compilation, and the kernel will decode the OOPS itself.
The OOPS output can be transcribed directly into an email message and then sent to the kernel list for prompt debugging by major kernel hackers.
Unfortunately, getting the word out about this change is not so easy. A lot of people just instinctively reach for ksymoops when they see an OOPS. Documentation about this change has been added to the kernel, and hopefully Linux users will gradually catch on to the new convenience.
The kernel boot code is a mess. Part of the problem is that it is written in complex assembly code, and making changes to fix one configuration would tend to break things in other configurations.
The solution does appear forthcoming. Etienne Lorrain has been hacking on this code since 1998, and his latest effort involves abandoning the unmaintainable assembly code and replacing it with clean C code. Beyond maintainability, there are several benefits to his approach, as well as some problems.
For one thing, the kernel would no longer have such tight size limitations. As Etienne demonstrated, his new code allows a large kernel, compiled with all available configuration options turned on, to actually boot. With the official tree, this is not possible.
Also, BIOS detection is done in real mode. The function to do this in Etienne's code can be much larger than it is in the official tree, allowing nice frills like screen output revealing problems.
Remaining in real mode for BIOS detection also means that the BIOS still works at that time, as opposed to the situation with the official tree, where the kernel switches to protected mode for a period of time early in the process, thus invalidating some BIOS data.
On the other hand, Etienne's proposal radically changes the way we can boot the kernel. Support for Lilo and Grub would be lost. Actually support could be regained, but only with additional assembly code. As an alternative, Lilo and Grub could be modified to support Etienne's new setup. However, the Lilo source is so scary that Etienne doesn't want to touch it, and adding support to Grub would also lose the BIOS benefits obtained in Etienne's current code.
Sometimes the biggest obstacle to a given kernel feature is the maintainer.
Hans Reiser, for instance, started off humble enough, thanking people for their contributions and suggestions and requesting that Reiser4 be accepted into the official kernel. But soon he was saying things like, "Most of my customers remark that Namesys code is head and shoulders above the rest of the kernel code." Soon the insults were flying, and no work could be done.
Christoph Hellwig, who had always given careful feedback to the Reiser code submissions, eventually bailed, saying he wouldn't look at any more Reiser code if it meant he'd have to endure insults and attacks.
ReiserFS is certainly a very useful and popular filesystem with many good qualities. Hopefully the project leader will learn to accept criticism more graciously.