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
include file with prototypes for the various
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
), 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
Comments (3 posted)
Kernel development news
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
Comments (none posted)
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 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
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)
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
- Andrew Morton: 2.6.3-mm2.
(February 22, 2004)
- Andrew Morton: 2.6.3-mm3.
(February 24, 2004)
Core kernel code
Filesystems and block I/O
Benchmarks and bugs
Page editor: Jonathan Corbet
Next page: Distributions>>