Kernel development [LWN.net]

Release status

Kernel release status

The current stable 2.6 kernel is 2.6.13.1, which was released on September 9. It includes about ten patches, including fixes for two known security issues.

The current 2.6 prepatch is 2.6.14-rc1 released by Linus on September 12. Here is the announcement from Linus. 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, and v9fs.

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 enhancements.

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

Quote of the week

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)

Toward merging reiser4

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 current setup.

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)

Some API changes for 2.6.14

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 sk_buff structures:

    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

Kernel trees