Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is still 2.4.0-test11. The 2.4.0-test12 prepatch is up to 2.4.0-test12-pre7. This release contains the beginning of the integration of support for the HP PA-RISC architecture; it's unlikely, however, that 2.4.0 will actually have the full PA-RISC support in it. Evidently some of the PA-RISC changes reach into the generic code, and that's a bit more than Linus wants to try to put in so late in the game. There's also the usual big pile of fixes, including some IRQ tweaks that should help people with laptop problems and some changes to how exec_usermodehelper() (used to run modprobe for dynamic module loading) works.
Also in the pre7 prepatch is a fix for an "embarrassing" USB error which will likely fix a lot of known USB problems and the removal of the tq_scheduler task queue (see below).
The current stable kernel release is still 2.2.17. No new 2.2.18 prepatches have been released this week.
The demise of tq_scheduler. The kernel is, in theory, in a code freeze preparatory to the release of 2.4.0. That does not mean, however, that fundamental changes will not happen. With 2.4.0-test11 came a new function called schedule_task. It works like the familiar task queue interface in that it allows the kernel code to "set aside" a task to be executed soon, at a time when nothing more pressing is going on.
In particular, schedule_task works like the tq_scheduler task queue, in that the tasks will always be run in process context. With tq_scheduler, however, the process context used is arbitrary - it is whatever process is being scheduled out of the CPU at the moment. Running code in the context of random processes was never, perhaps, the most elegant thing to do, even if it has worked for years. So, with schedule_task, comes a new kernel thread called "keventd." Its only job is to run the scheduled tasks, so that they all run in a well-known context.
2.4.0-test12 will finish the job by removing all references to the tq_scheduler task queue. It's a far-reaching change, touching 29 files in the source tree. As such changes go, it is relatively safe, but it may well create incompatibilities with drivers and other modules that are maintained outside of the mainline kernel. And it is a surprising change to see this late in the development process.
A standard interface for network interface configuration? Ivan Passos started off an interesting conversation with this posting pointing out that Linux has no standard interface for configuring many of the parameters relevant to synchronous network interfaces. These parameters include the media type (v.35, T1, whatever), link-level protocol (PPP, HDLC, ...), clock source, etc. He expressed an interest in helping to implement an interface which would make it possible to configure all interfaces in a consistent manner.
It was quickly pointed out that this problem is not just limited to synchronous interfaces. Consider the choices available for the "standard" Ethernet interface:
Anybody who has had to configure more than one type of Ethernet interface in a situation where it didn't "just work" knows that there is very little consistency in how this configuration is done. Even the ifconfig media option is not implemented by all drivers. Often it comes down to a "use the source, Luke" approach to figure out just what the boot/load-time parameters for a particular driver are.
Of course, designing this interface is easier said than done. It's probably a matter of designing a set of ioctl calls around each networking technology, and trying hard to be sufficiently general to catch all of the important cases. Then there is the small matter of making all of the network drivers actually support this interface. It's a daunting task, but also an important one. Expect to see somebody take a shot at it sometime in the 2.5 development series.
Progeny releases nullfs. Progeny Linux Systems, as part of its NOW project, is creating a new network filesystem called "Pelican." As part of that process, the Progeny hackers have created a separate filesystem called "nullfs," which is intended to be used as a way of learning and understanding how filesystems interact with the Linux VFS layer. The first nullfs release is now available for download, and may well prove useful for others who would like to work with Linux filesystems.
Essentially, nullfs will allow a suitably privileged user to mount one directory on top of another, creating an active link between the two. Operations on the mounted filesystem generate a bunch of logging information, providing a window into how the VFS is calling the nullfs operations. Some more information, including a simple session log, can be found in the README file packaged with the nullfs release.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
December 7, 2000