Kernel development [LWN.net]

Brief items

Kernel release status

The current 2.6 kernel is 2.6.3; Linus has made no kernel releases or prepatches in the last week. His BitKeeper repository is full, however; it contains support for Intel's "ia32e" architecture (see below), a new syscalls.h include file with prototypes for the various sys_* functions, various network driver fixes, a UTF-8 tty mode, dynamic PTY allocation (allowing up to a million PTY devices), sysfs support for SCSI tapes and bluetooth devices, the "large number of groups" patch (covered in the 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.

Comments (3 posted)

Kernel development news

Quote of the week

I'm happy you put it that way, because otherwise I'd have had to take out my chain saw and run around naked trying to kill you.

-- Linus, as if the Australian swimsuit episode weren't enough.

Comments (none posted)

invalidate_mmap_range() again

The question of whether invalidate_mmap_range() should be exported to non-GPL modules was discussed here last week. There still has been no (public) resolution of the question as of this writing, but the discussion has progressed somewhat. This issue may give some hints as to how other export requests may be viewed in the future.

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.

Comments (11 posted)

Intel's new 64-bit architecture and Linux

Intel has run into a problem that, sooner or later, catches up with many major vendors in the computing industry: customers like standard technologies. It is difficult to introduce a product which ignores the prevailing standards - even if you are the company which set those standards in the first place. Thus, the "Intel" name has not been enough to push the industry toward its Itanium processors. Instead, vendors have been incorporating AMD's 64-bit processors, which retain x86 compatibility and extend that architecture in a relatively natural way.

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.

Comments (none posted)

CDROM drives and partitioning

It is rare for a CD to be built with partitions; in the modern world, a CD's capacity is considered small enough as it is without splitting it up further. Many of the other reasons for using partitions (robustness in case one partition's filesystem gets corrupted, containing excessive space usage, etc.) also do not apply to the CD medium. As a result, the Linux CD driver does not support partitioning at all.

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.

Comments (none posted)

Patches and updates

Kernel trees