What's not going into 2.6.18
The features which are expected to be merged are interesting, but they are best discussed once they hit the mainline repository; until then, their fate remains uncertain. So, for now, suffice to say that 2.6.18 will likely include an S/390 hypervisor filesystem, a number of memory management patches, some software suspend improvements, a new i386 hardware clock subsystem, some SMP scheduler improvements, the swap prefetch patches (maybe), priority-inheriting futexes, a rework of the /proc/pid code, a number of MD (RAID) improvements, a new kernel-space inotify API, and a bunch of code from subsystem trees which does not appear in -mm directly. As is usual, a great deal of code will be flowing into the mainline for the next release.
It can also be interesting to look at what will not be merged. From Andrew's posting, the following big patch sets are likely to be held back:
- There is a great deal of code which requires action by various
subsystem maintainers. But, says Andrew, "
I continue to have some difficulty getting this material processed.
" He will step up his efforts to get responses from maintainers, but some patches will likely continue to languish.In particular, some dismay has been expressed regarding how long it can take to get drivers into the mainline. It seems that, perhaps, the quality bar is being set too high. It is always possible to find things to criticize in a body of code, but sometimes the best thing to do is to proceed with the code one has and improve it as part of an ongoing process. There is concern that reviewers are insisting on perfection and keeping out code which is good enough, and which could be of value to Linux users.
- The acx100
driver supports a useful range of wireless chipsets.
Unfortunately, there are some concerns about how this driver was
developed and whether its inclusion could cause legal problems for
Linux. Until that issue is resolved, this driver is likely to remain
out in the cold.
- The per-task delay accounting patches are sitting on the edge. The
main concern here appears to be that these patches create a new
interface for getting per-task information from the kernel. Any other
new code which exports that sort of information (and a number of
patches exist) will be expected to use this new API. So more review
and discussion may be called for here. There is also a separate patch
set for non-task-oriented statistics which will probably not be merged
this time around for the same reason.
- eCryptfs is uncertain as
well. This filesystem implements its own mechanism for stacking on
top of a base filesystem, but the primary reviewer would rather see
the creation of a generic stacking layer for all to use. This is an
issue which is often encountered by people trying to do new things;
they are asked to make their infrastructure more generic. The intent
is good, but it can cause delays and extra work for developers trying to
add new features.
- The UTS namespaces patch. This patch, which implements a small part
of the container concept, is not particularly useful on its own. So
it will probably wait until more of the container infrastructure is in
place.
- The adaptive readahead
patches are deemed to be too young for now. Some benchmark
results show significant performance improvements from these patches,
but others are less clear.
- Reiser4. Says Andrew: "
We need to do something about this. It does need an intensive review and there aren't many people who have the experience to do that right, and there are fewer who have the time. Uptake by a vendor or two would be good.
" This filesystem has been waiting on the sidelines for a very long time, and no prospective merge is yet in sight. - The generic IRQ code is said to be "still stabilizing" and more likely to be merged in 2.6.19. That is also the case for the lock validator.
All of this is subject to change when the merge window actually opens.
Developers are making cases for specific patches; Ingo Molnar is asking for
reconsideration of the generic IRQ and lock validator patches, for
example. Watch this space in the coming weeks to see what really happens.
| Index entries for this article | |
|---|---|
| Kernel | Development model |