|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a 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. |
Pankaj Parakh wanted to try his own process scheduler in Linux and asked how he could plug his in to replace the primary scheduler. Actually, what Pankaj wanted was to create a whole in-kernel infrastructure to make it easy for anyone to plug in his or her own scheduler.
Peter Williams replied that he was in the process of revivifying the CPU plugin scheduler project and was renaming it CPU_PISCH. He invited Pankaj to join the project, and Pankaj said sure! So Peter sent him some patches and remarked that he was also working on a new scheduler of his own that he was waiting to finish before releasing as patches.
It's nice to see a project like this - it's fun to make it easier for people to play around with fundamental kernel behavior. Linus Torvalds has said that he wants only a single scheduler in the kernel, so this project might be a patches-only thing for quite some time. If it gets very popular and accrues many contributors, Linus might ultimately reconsider. But as a feature, it seems unlikely that CPU_PISCH will ever have end-user appeal. Time will tell.
http://lkml.org/lkml/2009/10/11/253
http://lkml.org/lkml/2009/10/27/50
Sam Ravnborg has stepped down as the Kbuild maintainer. This was greeted with dismay by folks such as Andrew Morton, and Theodore Y. T'so, David S. Miller, Randy Dunlap, Stephen Rothwell, and many others thanked Sam for being maintainer for so long. Sam did not make arrangements for a new maintainer, but he also added, "I do not get many complaints about kbuild these days. All the basic stuff just works."
Anibal Monsalve Salazar volunteered to maintain Kbuild. Michal Marek also said he'd like to do it and suggested that the two of them work together. Anibal liked this idea, and it seems that Kbuild now has two new co-maintainers.
http://kbuild.sourceforge.net/
LogFS has recently made some impressive strides. The flash filesystem is intended for larger devices than its compatriot JFFS2 can easily support. But LogFS has been undergoing some changes that have made it less welcome in the official kernel - specifically, changes to the on-disk data format were needed. When a filesystem that already exists in the kernel changes its disk format, existing users of the old format still need to be supported, and this forces the kernel to maintain multiple codebases for each version of the filesystem that changes the on-disk format. The last time LogFS developers tried to get it into the main kernel, Linus Torvalds told them to come back when the disk format had stabilized.
Recently, Jörn Engel did just that. He posted to linux-kernel, saying that the disk format was stable, that other improvements had been made, and that he wanted to submit the code for inclusion. Arnd Bergmann said the code looked great and that merging was way overdue. Jörn asked Stephen Rothwell to add LogFS to the Linux-Next tree, and Stephen did so, thus slating the patches for the next Linux merge window.
Mathieu Desnoyers recently announced that LTTng (Linux Trace Toolkit Next Generation) version 0.164 would involve relicensing the bulk of the code to stick with the GPL, now also to include the LGPL; some of the code is to be dual licensed under the GPL and the BSD licenses. Mathieu was still waiting for permission from IBM to include some of their contributions in the relicensing.
Michael Cree was disturbed by the number of unimplemented system calls on the Alpha architecture - more than a dozen of them. He volunteered to implement some of them, but he wasn't sure which were the most straightforward, and he didn't know whether the system call table had to be kept in the same order as on other architectures. Matt Turner said that he'd also considered implementing these system calls, but he'd had similar technical questions. It seems that they intend to work on this together.
Matthew Wilcox has posted patches to allow SysFS to be populated dynamically. The standard way is for SysFS to be hard-coded in the source tree, but Matthew was able to use his patches to get a bootable system. He cautioned any interested users to beware of races and missing features, and he urged interested contributors to be careful in all implementation changes.
Clearly SysFS is a very deep and dangerous part of kernel configuration, and a solid implementation is crucial. Traditionally SysFS has been only one of many alternative approaches to run-time kernel configuration. ioctls, ProcFS, and other infrastructure have all been tried. SysFS is one of the top contenders to replace all the others, and much care is undoubtedly required in designing features like this one.
http://lkml.org/lkml/2009/10/20/28
http://lkml.org/lkml/2009/10/20/32
A movement among various top kernel folks - not without its controversy - has begun to give subsystem maintainers the leeway to move any drivers they don't like into the "Staging" tree in preparation for ultimately removing them from the kernel entirely if their code doesn't get fixed up. Bartlomiej Zolnierkiewicz felt this would open up the doors for abuse, but Greg Kroah-Hartmann and Alan Cox felt that plenty of safeguards were in place. As Alan pointed out, Greg administers the Staging area, and Linus Torvalds would also pipe up if subsystem maintainers seemed to be abusing the privilege. As David S. Miller pointed out, anyone who's an official maintainer could conceivably abuse that authority, and if the community exists in a spirit of cooperation, this new approach to the Staging tree wouldn't harm that. And as Greg said, this type of policy shift could easily be reexamined later.
Ingo Molnar also remarked, "Note that nothing has changed: the same fine folks who worked for 15+ years to give you the OS with the most built-in drivers on this planet (more than 3000 drivers today and counting) are handling this too."
For the moment, it does seem as though there's sufficient interest that this policy will be put into place; the result will probably be a dramatic increase in code quality inside the kernel, a dramatic decrease in the number of broken and unused drivers in the kernel, and probably a fair increase in the number of coders protesting that their code has been summarily migrated out of the kernel.
http://lkml.org/lkml/2009/10/15/250
http://lkml.org/lkml/2009/10/15/259
http://lkml.org/lkml/2009/10/15/269
While many kernel developers were asleep in Japan during the kernel summit, John Hawley decided to sneak in under the cover of darkness and upgrade the operating system on master.kernel.org. He expected this to take no more than six hours and would involve rebooting. He figured the load on the server was about as low as it was every going to get, so the time was right. He did the upgrade, and, aside from a few straggling upgrade issues, he made it in under the six-hour window.
http://events.linuxdoundation.org/archive/2009/kernel-summit