Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.39. It was a busy week in terms of kernel releases - three have come out since last week's LWN.
The current stable kernel release remains 2.2.14. Evidently a few small glitches have turned up with this release; as a result, 2.2.15 will probably come out fairly soon, and will contain nothing but bug fixes. The first prepatch, 2.2.15pre1, is available now. Larger changes, such as new device drivers, will be held back to 2.2.16 at the earliest.
The current ancient kernel release remains 2.0.38, but work is in progress to produce a 2.0.39. Alan Cox has announced the release of the first 2.0.39 prepatch. The actual work for this release is being done by David Weinehall; he hsa sent out an announcement of his own, which lists the changes in this release. New 2.0 releases will only contain serious bug fixes, 2.0 users should not be expecting a whole lot of new features.
Changes to the block (disk) device interface were one of the bigger surprises this week. Alexander Viro sent out this note describing the new interface; it includes the creation of a new block_device structure. The new structure replaces the standard file_operations structure in a number of contexts; a couple of file_operations methods (revalidate and check_media_change) are disappearing from that structure altogether. The result, it is hoped, will be a cleaner and more capable interface to block devices.
Needless to say, this announcement got some reactions. Almost all device drivers, and certainly all block drivers, will be affected by this change. Some device writers have gotten a bit grumpy about yet another kernel API change that they will have to deal with. The kernel developers, however, strongly defend their right to change the API in development releases; the alternative is to slowly build up a crushing load of compatibility cruft. The right to change things creates ongoing pain for driver maintainers, but helps to maintain the quality of the Linux kernel code in the long term.
It is surprising, however, to see a major core API change come in this late in the development cycle. In theory, the kernel is in a feature freeze, and the interfaces should remain stable. The fact that this sort of change continues to make it into the 2.3 series reinforces the fact that the 2.4 release is still distant.
The 32-bit UID changes are also significant - they touch many parts of the kernel. An overview of the issues involved can be found in the highuid.txt file included in the Documentation directory. Among other things, disk quotas could have problems as a result of their use of the UID to index into the quota file, the accounting file format uses 16-bit UIDs, all the filesystems need to be checked over, the core dump format only supports 16-bit UIDs, and more. Cleaning up everything and making sure it all works is not going to be a small job. Nonetheless, this is a much-requested feature, and quite a few users will be happy to see it get into 2.4.
/proc and /proc/sys. Linus stirred up a bit of a storm by proclaiming that the sysctl interface (and, by extension, /proc/sys) is deprecated. Sysctl, of course, provides controlled access to internal kernel variables; for example, the file
/proc/sys/net/ipv4/ip_forwardcan be queried to see whether packet forwarding is enabled on the system, and writing a new value to that file will change that status. The sysctl() system call interface also provides access to sysctl variables.
Linus wants to move away from sysctl, and toward putting everything in /proc. His reasoning is essentially that sysctl is an inappropriate interface for the type of access needed. There is resistance to that approach, however, stemming from the fact that a number of people do not really like /proc. There appear to be two objections:
The likely outcome appears to be "more of the same," with /proc and sysctl continuing to coexist.
Other patches and updates released this week include:
Section Editor: Jon Corbet
January 13, 2000