On the Desktop
Linux in the news
All in one big page
See also: last week's Kernel page.
The current kernel release is still 2.4.5. Linus released 2.4.6pre3 on June 13. It includes a relatively large set of fixes and updates, including the long-awaited fix that allows ReiserFS filesystems to be exported by NFS; a number of virtual memory updates; a bunch of virtual filesystem cleanups by Alexander Viro; and many other fixes. Linus didn't see fit to mention it, but, as of pre2, the kernel also contains a Bluetooth protocol implementation.
The VM changes include work from a number of developers. After some rigorous testing here at LWN Labs (i.e. "run it on your desktop and see what happens"), we conclude that a number of the VM issues have, in fact, been addressed. It is not perfect, yet, but progress is being made. It's nice to have a system that doesn't seem to be running out of swap all the time.
On the other hand, there have been reports of compile-time warnings due, as it turns out, to a change in the PCI bus API. One might object that this is supposed to be a stable kernel series; evidently the kernel developers concluded that there were few users of this particular interface and a change would not cause problems. Some people disagree, however.
The 32-bit DMA zone patch, covered last week, is still not present in the 2.4.6 prepatch. Linus likes the idea, but wants some changes which create a new interface for setting up memory zones in a more flexible manner.
Alan Cox's latest is 2.4.5ac13. Alan is evidently doing jury duty, and has thus been relatively quiet.
A new networking patch pushes the limits of what modules can do. La Monte Yarroll is working on the Linux Kernel SCTP project, which is producing a Stream Control Transmission Protocol implementation for Linux. The SCTP folks have found that it is hard to just plug a new networking protocol into the kernel - the interfaces are just not set up for that.
So Mr. Yarroll has posted a patch which creates a new registration interface. The current static tables are replaced with a dynamic structure, and a set of functions has been provided which allows a module to add its new protocol to the system. It seems like a useful patch, which should not be overly controversial.
Until, that is, somebody asked if this interface could be used to replace the TCP implementation in the kernel. The answer was "yes," though any hopes of having the new implementation pick up existing connections should be forgotten.
Here's David Miller's take on the idea of plugging in new TCP implementations:
I will never in my lifetime allow such a facility to be added to the Linux kernel.
One might safely conclude that he does not like the idea.
The problem is that David does not want to open the door for people to plug proprietary TCP implementations into the kernel. Linus has, of course, said that non-free kernel modules are OK, as long as they stick to the published module interface. That interface currently does not allow the replacement of network protocol stacks, so the only way to do so would be to link the new implementation directly. Doing so with a proprietary implementation would clearly violate the GPL. Mr. Miller (and many others) are happy with that state of affairs.
This approach is not particularly new or surprising - Linus does not allow modules to add new system calls for the same reason. Binary-only kernel modules are tolerated, grudgingly, but only for certain tasks, such as driving devices. "Embracing and extending" the kernel by replacing whole subsystems goes a little too far. Of course, as was covered on the LWN front page two weeks ago, some people think that even Linus's interpretation is too liberal.
So the registration patch will probably see some minor reworking so that it does not allow the replacement of existing network protocols. But the issue of binary modules is likely to return, soon. There may yet come a point where they are no longer allowed.
The kernel and data formats. Another area of ongoing discussion has to do with how the kernel returns data to user space. Last week's Kernel Page mentioned the discussion of temperature formats; this discussion is worth revisiting (along with one other) because they illustrate how some kernel interface decisions are made.
Last week we reported that kelvins were the likely choice of units for temperatures reported by CPU monitors and such. In fact, a number of people have been advocating for temperatures to be reported in tenths of kelvins, or even hundredths. The stated advantages of this format are that the numbers will always be non-negative, and that a very wide range of temperatures can be represented with 16 bits - a wider range, certainly, than most computers will endure and be expected to still function. Or so it seems.
The assertion that kelvins can not be negative was quickly refuted, but the argument is mostly of interest to pedantic quantum physics enthusiasts. Once again, this is not within the normal operating specifications of current commodity hardware.
Using anything other than straight kelvins has also been controversial. The point being made is that returning a value in hundredths of kelvins might fool people into believing that the temperature measurements are actually that accurate. One degree of precision is more than adequate for modern CPU temperature sensors, and a more precise measurement would be useless even if it were accurate.
Nonetheless, there are people who would like the more precise format, for the simple reason that it may be needed in the future, and these interfaces are hard to change once they are in use. A final resolution has not happened, but a likely format will be tenths of kelvins, since ACPI already uses the format.
Some people have argued for a system configuration option which would allow selection of whatever temperature unit pleases the user best. That didn't get very far, though. There is a near consensus that the kernel should export a single, well-defined format, and leave conversions to user space.
The same idea, however, created a bit more fuss at the end of May, when a new version of the Phillips web camera driver was merged with its color conversion routines stripped out. As a result, applications using that camera see only one format, and many of them apparently do not understand it. The pwc driver author has summarized his position, along with much of the discussion, on his web page.
The argument here is the same: the kernel should export a single data format, and leave conversions to user space. In the case of web cameras, the kernel hackers would much rather see a single, user-space conversion library, rather than a whole set of duplicated conversion routines in each driver. Driver writers, who want to make their devices easily usable, may disagree, however. The kernel hackers say what goes in, though, so this policy is likely to remain.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
June 14, 2001