Linux in the news
All in one big page
See also: last week's Kernel page.
The current kernel release is 2.4.12. Linus released 2.4.11 shortly after last week's LWN Kernel Page went to "press," only to discover that it contained an unpleasant bug: creation of files via a dangling symbolic link would cause filesystem corruption. So he rushed out 2.4.12 with a fix for that problem and a few other tweaks as well.
One of those tweaks, unfortunately, was a parallel port change that fails to compile. As Linus said, "not a good week." In the same message, he also put out this teaser:
On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things ;)
As of this writing, 2.5 still does not exist. There also is no 2.4.13; Linus evidently decided to take a more deliberate pace with the next release. Those wanting to build 2.4.12 should apply the fix for the parallel port problem first.
2.4.12 also has a problem in the disk partition code that can cause partitions to disappear. There is a fix available for that problem as well
Alternatively, of course, there is the latest prepatch: 2.4.13-pre4. It contains those fixes along with several others, and "continued merging" from the "ac" series.
Speaking of which, Alan Cox's latest is 2.4.12-ac3. It contains a much-awaited ext3 filesystem update, a bunch of ARM fixes, and many other tweaks and updates.
The benchmarks I've seen says that the simple VM performs better - both in terms of repeatability and in terms of absolute performance.
Alan Cox, meanwhile, says that he has "not reached any final conclusions on the VM." He is apparently still waiting to see how things settle out before deciding which implementation he wants to go with. Given that he is the "maintainer apparent" for 2.4 in the near future, his decision will be important.
Randy Hron has published the results of some performance testing on a few VM implementations. The testing involved running a Linux Test Project utility to allocate most of the available virtual memory, while simultaneously playing music out his sound card. Some of his findings:
Conclusions are hard to draw at this point. Both 2.4 virtual memory implementations are improving under the pressure of the competition between the two trees. At some point, this issue will have to be resolved; in the mean time, more hacking and benchmarking appears to be called for.
Modules, symbols, and licenses. There has been a scattered report or two of module loads failing in recent kernels due to conflicts with GPL-only symbols. These are actually a little surprising; the 2.4.12 kernel supports the EXPORT_SYMBOL_GPL macro, but no symbols are yet exported in this mode. The real problems are almost certainly elsewhere; the module loading code is just trying to be helpful by pointing out, when loading non-GPL modules, that the license may be the problem.
The other half of that problem is that not all GPL-licensed modules have yet been fixed up with the appropriate MODULE_LICENSE tags. Thus causing the GPL complaint when loading the loop driver code, which is part of the kernel and has been covered by its license since 1993. A truly stable kernel would not have glitches of this variety, but....
A different change is coming in 2.5. Way back in 2.0, any symbols (variables) defined within a module would (1) be available for setting by the user at module load time, and (2) be exported to the rest of the kernel. In 2.2, load-time variables were tightened up; only variables which were explicitly designated can be changed when loading the module. But, unless the module declares explicitly to the contrary, all global symbols in the module will still be exported to the kernel.
In 2.5, that will change; no symbols will be exported without explicit instructions to that effect. The module code is going to be more restrictive than that, however: if a module does not state its intention with regard to symbols one way or another, the system will refuse to load it. In the words of Keith Owens, the perpetrator of this change, "That will break a lot of modules."
The fix for broken modules is usually easy. Very few kernel modules actually need to export symbols to the rest of the kernel; simply adding an EXPORT_NO_SYMBOLS line will make that explicit and allow the module to be loaded. There are those who would rather see EXPORT_NO_SYMBOLS simply become the default, avoiding the need to edit large numbers of modules. Keith's reasoning for requiring the change is to force somebody to actually look at each module and see what its symbol needs really are.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
October 18, 2001