Brief itemsthe October 2 Kernel Page), the generic kernel thread code (January 7 Kernel Page), and a massive number of other fixes -- over 500 changesets in all.
It's worth noting that Linus is now using a PPC64 system as his home machine. Before long that should result in improved support for that architecture; meanwhile, he finds himself unable to fix his own kernel.
The current tree from Andrew Morton is 2.6.3-mm3. Recent additions to the -mm series include a new HFS filesystem implementation, multipath and crypto target support in the device mapper, a big ide-scsi update, the MODULE_VERSION macro (finally), some virtual memory tweaks, a (read-only) UFS2 filesystem implementation, a big set of parallel port fixes, many big architecture updates, and a large number of fixes.
The current 2.4 kernel is 2.4.25. Marcelo has started off the 2.4.26 process with 2.4.26-pre1; it contains a small set of fixes and a fair number of networking patches, including an SCTP update, a bonding driver update, and the nVidia Force driver.
For 2.2 users, Marc-Christian Petersen has released 2.2.26, which contains the latest security fixes.
Kernel development news
Andrew Morton posted two criteria which should be used in considering the request. The first is: does the export make sense from a technical point of view? In other words, is the ability to clear page table entries which point at the page cache a legitimate feature for filesystems to want? The consensus answer here appears to be "yes"; distributed filesystems, in particular, will need this capability.
Andrew also noted that the technical question really should be the only one that matters. If there is a valid technical reason for filesystems to use that function, it should be exported to them. In the real world, however, a second question must also be considered: is IBM's proprietary GPFS filesystem, being the module driving the proposed export change, a derived product of the kernel or not? Here there is less of a consensus.
IBM's claim is that GPFS was developed under AIX and simply ported to Linux; it is thus an independent development and clearly not derived from the Linux kernel. Critics point to the large, BSD-licensed layer of glue code which is required to make GPFS actually work with Linux; this layer, they say, shows that GPFS does so much messing around with kernel internals (rather than using the existing, exported interface) that it must be a derived product. Interestingly, IBM supporters also point to the large glue layer. If GPFS were truly derived from the kernel, they say, there would be no need for a large impedance-matching layer.
Without access to the GPFS source, it is going to be hard for any independent party to make a real determination on the status of GPFS. In the end, however, somebody is going to have to make a decision anyway. The odds would appear to favor IBM getting what it wants in this case. But a clear message is being sent: the kernel developers are increasingly suspicious of (and hostile to) changes which make life easier for vendors of closed-source modules.
In response, Intel has finally unveiled its own 64-bit extensions, under the "ia32e" name. Intel itself does not say this, but a review of the new architecture revealed fairly quickly that Intel has adopted (for the most part) AMD's 64-bit architecture. Intel is now in the business of selling AMD-compatible processors. Linus was rather annoyed at Intel for not coming out and just saying this, to the point that he toyed with the idea of renaming the kernel's x86-64 architecture "AMD64." Calm thinking prevailed, however, and Linus chose to stick with a vendor-neutral name.
Support for the new architecture has already been merged into the (upcoming) 2.6.4 kernel; the patch came from Andi Kleen. Given the great similarities with the AMD64 architecture, this support was relatively easy to implement. Intel may not have been entirely straightforward about the path it has taken, but, where it matters, Intel has done the right thing.
It turns out, however, that some companies do produce CDs with partition tables on them. Linux systems will be unable to mount and read the filesystems on such CDs. Most users have never encountered this problem, but, for those who have, Steven Hill has posted a patch which adds CDROM partition support to the SCSI CDROM driver.
The good news is that, in the 2.6 kernel, the block layer handles partitioning. So the active part of the patch boils down to the following:
- disk = alloc_disk(1); + disk = alloc_disk(partitions + 1);
So it turns out to be a relatively easy patch to design and implement. (See this Driver Porting Series article for details alloc_disk() and the rest of the 2.6 gendisk interface).
The only problem is that, as one might expect, the minor device numbers for the partitions will be allocated immediately after the minor number for the CD device as a whole. /dev/scd0, the first SCSI CDROM device, has device number 11,0, so the first partition on that device would be assigned numbers 11,1. The only problem is that 11,1 is where most systems expect to find /dev/scd1, the second CDROM device. No space was ever set aside for partitions in the SCSI CDROM device number range.
In the relatively near future, dealing with this sort of issue will not be a problem; a small set of udev rules will ensure that the right device names are created to correspond to the hardware which is actually present on the system. Until then, however, users of partitioned CDs will have to deal with a conflict in how the kernel and the distributions see the SCSI CD device number space.
Patches and updates
Core kernel code
Filesystems and block I/O
Benchmarks and bugs
Page editor: Jonathan Corbet
Next page: Distributions>>
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds