The current stable 2.6 kernel is 220.127.116.11
, which was released
on September 9.
It includes about ten patches, including fixes for two known security
The current 2.6 prepatch is 2.6.14-rc1 released by
Linus on September 12. Here is
According to the revised development process, this release should contain
all of the major patches that will go into 2.6.14; everything from now on
should be a bug fix. So it looks like 2.6.14 will include the ipw2100 and
ipw2200 wireless drivers, the HostAP system (which allows a Linux
system with suitable hardware to function as a wireless access point),
version 19 of the wireless extensions API, relayfs, a large InfiniBand
update, an abstraction layer for ethernet PHY devices, four-level page
table support for the ppc64 architecture, a big netfilter update, a DCCP implementation, the filesystems in user space patch,
Other changes of note include the "sparsemem extreme" patches (preparing
for hotplug memory), a NUMA-aware slab allocator, kzalloc(), a number of
swap file improvements, some kernel build system improvements, some klist API changes, a serial ATA
update (with a Marvell driver supporting PIO mode only), ongoing work to
shrink the sk_buff structure, and some block subsystem
The current -mm tree is 2.6.13-mm2. Recent changes to
-mm include some token-based swapping tweaks, some memory hotplug work, a
PCMCIA update, and the usual pile of fixes. The -mm tree has shrunk
considerably as patches have flowed into the mainline.
Your editor is out of town this week, so the Kernel Page will be a bit
thinner than usual. Everything should be back to normal next week.
Comments (3 posted)
Kernel development news
We should have a strict rule: anybody who adds things like
"must_check" and "deprecated" had better also be ready and willing
to fix all the new warnings they cause - you're not allowed to just
assume that "somebody else will fix it".
-- Linus Torvalds
Comments (2 posted)
The reiser4 filesystem has been the subject of a long, ongoing conversation
for many months; look under "reiser4" in the LWN Kernel Page Index for
previous coverage on this page. The reiser4 developers have been working
hard to get their new filesystem merged into the mainline kernel, and they
believe that the time has come. To that end, Hans Reiser has posted a list of concerns raised by others. His hope
is to get definitive answers on what has to be done to get reiser4 in,
hopefully for 2.6.14.
One of the big issues since the beginning has been the reiser4 metafiles
feature, where every file can, itself, be treated as a directory with the
file's attributes accessible as files in their own right. This feature
raised many eyebrows just by looking weird and non-Unix-like, but the real
issue was one of locking. The Linux virtual filesystem code is simply not
set up to handle files as directories, so it is easy for a user to deadlock
the system. Even Hans Reiser, a strong defender of the metafile feature,
sees these deadlocks as an undesirable thing.
So, while reiser4 has been in -mm for quite some time, the metafile feature
has been disabled. There is no talk of turning it back on for a mainline
merge; the real issue, instead, is whether the code should be allowed to
remain at all. The consensus on the kernel side would appear to be that
unused code does not belong in the kernel, so the metafile implementation
is likely to be removed altogether. Someday, if the locking issues are
resolved, it might yet return.
Reiser4 has long had trouble working with 4K kernel stacks (see last week's Kernel Page). It
would appear that this issue has now been resolved. Another complaint
which has been raised has to do with a large number of debugging tests in
the code itself; some developers see it as clutter and would like it to be
removed. Here, however, Andrew Morton has sided with the reiser4 hackers
and told them to leave the tests in.
Reiser4 implements a couple of its own types for condition variables and
linked lists. In both cases, it is thought that the in-kernel primitives
could be used, rather than introducing new, redundant types. Those will
probably have to be fixed before this code can be merged.
The end result is that quite a bit of work remains to be done, meaning that
it is unlikely to be ready before 2.6.14 closes to new features. Andrew
has hinted that reiser4 might just slip in
after the deadline, though:
But something like a brand new filesystem can go in pretty much any
time, as long as it compiles. Because it can't break anyone's
The one issue which, interestingly, has not come up in the recent
discussion has been the plugin architecture used by reiser4. To a number
of developers, that sort of feature does not belong at the individual
filesystem level; it should, instead, be made part of the VFS layer and
made available to all filesystems. It would appear that a more moderate
viewpoint, allowing the feature to be merged now with the idea of shifting
it up into the VFS over time, has won out.
Comments (7 posted)
From what has been merged as of this writing, it appears that the 2.6.14
kernel will have few API changes which will break code. The changes which
have been merged are mostly additions to the kernel API. Here is a quick
discussion of a few of them.
Some previously-discussed additions have finally made it to the mainline.
One of those is kzalloc(), which
allocates pre-zeroed memory. The two new variants of
schedule_timeout() (which perform the setting of the task
state) have also been merged.
Speaking of task states, there is now a TASK_NONINTERACTIVE flag
which is used to mark non-interactive sleeps. It should be set alongside
TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE in cases where
the fact that a process is sleeping does not provide any information on
whether it is interactive or not. Its initial use is for processes waiting
on pipe buffers; the idea is to keep batch tasks using pipes (such as
kernel compiles) from looking more interactive than they are.
Ingo Molnar's spinlock consolidation patch
has gone in. This change should not affect much outside of the spinlock
implementation, but it effects some major cleanups inside. There have been
a number of simplifications and enhancements applied to the spinlock
debugging code in particular.
On the networking side, there is a new function for allocating
struct sk_buff *alloc_skb_fclone(unsigned int size,
unsigned int priority);
This function is meant to be used for SKBs which are expected to be cloned
over their life cycle. It actually allocates a pair of sk_buff
structures, with the idea that the second can be used at
skb_clone() time without having to perform another memory
allocation. Some reference count tricks are used to know when the whole
assembly can be freed.
The net_device structure has long contained a
get_wireless_stats() method, used by wireless network drivers. A
previous update of the wireless extensions API moved that method over to
the iw_handler_def structure, but still continued to use the older
form when present. Wireless extensions 19 maintains that compatibility a
little longer, but now issues a warning when a driver uses the older API.
The block layer API has seen some enhancements. There is a pair of new
functions for creating I/O requests out of kernel buffers:
struct bio *bio_map_kern(request_queue_t *q, void *data, unsigned int len,
unsigned int gfp_mask);
struct request *blk_rq_map_kern(request_queue_t *q, int rw, void *kbuf,
unsigned int len, unsigned int gfp_mask)
The first will create a BIO structure out of the given kernel buffer (which
should not be space obtained with vmalloc()). The second takes
the additional step of queueing the request onto the given request queue.
There is also a new blk_rq_map_user_iov() which is intended to
work with the sg_iovec structures used in the SCSI layer.
As of this writing, the discussion of removing devfs has started up
again. That may not happen for 2.6.14, but it would be surprising, at this
point, if the devfs API lasted into 2.6.15.
Comments (2 posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Forrest Cook
Next page: Distributions>>