Crunch time continues: the merge candidate list v1.1

Okay, I've got Rusty's list collated with my list, plus several replies to each thread.

There is no WAY all of this is making it into the 2.5 tree before the freeze, but this is what's currently being submitted for consideration.

Rob

----

Linus returns from the Linux Lunacy Cruise after October 27th. The following features aim to be ready for submission to Linus by October 27th, to be considered for inclusion (in 2.5.45) before the feature freeze on October 31.

Note: if you want to submit a new entry to this list, PLEASE provide a URL to where the patch can be found, and any descriptive announcement you think useful (user space tools, etc). This doesn't have to be a web page devoted to the patch, if the patch has been posted to linux-kernel a URL to the post on any linux-kernel archive site is fine.

If you don't know of one, a good site for looking at the threaded archive is:
http://lists.insecure.org/lists/linux-kernel/
and a more searchable archive is available at:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=mlist.linux.kernel

Another good resource is http://kernelnewbies.org/status, from which about half this list was shamelessly ripped. :)

And now, in no particular order:

============================ Pending features: =============================

1) Roman Zippel's new kernel configuration system.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6898.html

Code: http://www.xs4all.nl/~zippel/lc/

2) Ted Tso's new ext2/ext3 code with extended attributes and access control lists.
Announce: http://lists.insecure.org/lists/linux-kernel/2002/Oct/6787.html

Code: bk://extfs.bkbits.net/extfs-2.5-update http://thunk.org/tytso/linux/extfs-2.5

Andreas Dilger says ext3 EA+ACL is now in the -mm tree.

3) Linux Trace Toolkit (LTT) (Karim Yaghmour)

4) PCMCIA Zoom video support (Alan Cox) (in -ac tree)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html

5) Device mapper for Logical Volume Manager (LVM2) (LVM2 team) (in -ac tree)
http://www.sistina.com/products_lvm.htm

6) VM large page support (Many people) (in -mm tree)
http://lse.sourceforge.net/

7) Page table sharing (Daniel Phillips, Dave McCracken) (in -mm tree)
http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35
(A newer version of which seems to be at:)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html

8) Dynamic Probes (dprobes team)
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes

9) Zerocopy NFS (Hirokazu Takahashi)
http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html

10) High resolution timers (George Anzinger, etc.)
http://high-res-timers.sourceforge.net/

11) EVMS (Enterprise Volume Management System) (EVMS team)
http://sourceforge.net/projects/evms

12) Linux Kernel Crash Dumps (Matt Robinson, LKCD team)
http://lkcd.sourceforge.net/

13) Rewrite of the console layer (James Simmons)
http://linuxconsole.sourceforge.net/

14) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html

15) USAGI IPv6.

Yoshifuji Hideyaki points out that ipv6 is very important overseas (where some entire countries make do with a single class B ipv4 address range). He says:

16) MMU-less processor support.

======================== Unresolved issues: =========================

1) Kernel Probes (Vamsi Krishna S)

Is this the same as dynamic probes?

2) In-kernel module loader (Rusty Russell)
3) Unified boot/parameter support (Rusty Russell)
4) Hotplug CPU removal (Rusty Russell)

Awaiting URLs from Rusty.

5) hyperthread-aware scheduler
6) connection tracking optimizations.

No URLs to patch.

7) IPSEC (David Miller, Alexy)
8) New CryptoAPI (James Morris)

Note, this may conflict with Yoshifuji Hideyaki's ipv6 ipsec stuff. If not, I'd like to collate or clarify the entries.)

10) Unlimited groups patch

Awaiting URL from Tim Hockin.

One thing that at least has to make it in for generic cd recording to be useful, is my sgio patches. Latest dump of just that is here:

*.kernel.org/pub/linux/kernel/people/axboe/patches/v2.5/2.5.44/

Same ones as posted under the 'zero copy dma cd writing and ripping' the other day, however patch also fixes several races and just plain sloppy code (sorry Linus). So that's pretty much a given.

Some of the items on this list seems to be more driven by naive corporate hope rather than reality...

Oh, and why

Hans thinks there's a chance in hell that anyone would want to merge code that's never actually been posted anywhere yet (do correct me if I'm wrong, but not even Hans gave me a straight answer on that one) is beyond me.

Jens Axboe

It is marked experimental. This is not an upgrade to "reiserfs", this is a completely separate "reiser4" filesystem with no code in common that you won't even be aware of unless you click on experimental drivers desired. Please remember that we do a good job with QA, so in evangelical efforts to impose a sense of severe feature freeze, please target past offenders we won't name here who deserve the attention. I see no point in burdening users when there are bugs we are able to hit ourselves, and that is part of why the delay.

Also, last time I spoke with Linus I said that freezes for filesystems should occur not less than 6 weeks after freezes for VM and VFS, and he agreed with that. I would prefer not to hold him to his past statements, but if I must then I will try to.;-)

On the other hand, if there are persons who would like to give us a hand with debugging and tweaking reiser4, we will be happy to send them tarballs. Such tarballs would be for developers, not users. What we need help with on reiser4 is probably just the sort of thing a weekend coder can enjoy. We need people hitting and patching bugs, and we need persons carefully employing a profiler and tweaking code paths. Persons who are interested in that would be very appreciated.

So, in summary, we should be included because we harm no other code (we are non-core), marked experimental, you know from the past that we will get it debugged, by next week we really will be in need of feedback from others, and because increasing Linux filesystem performance by 50-105% is worth some inconvenience.

We are currently figuring out why reiser4 went in the last 2 weeks from 105% faster than V3 to only 50% faster, and we want to fix it before we release. (I am pretty sure I know why it was.)

See www.namesys.com/v4/fast_reiser4.html for some details on what we implemented.

Hans

On Mon, Oct 21 2002, Hans Reiser wrote:
[snipped]

My point is that no code gets into the kernel without having a significant amount of exposure first. This means exposure to other developers, and exposure to users. Why do you think reiser4 is different from other projects in this regard? It definitely is not.

I can sort-of agree with that. Fixing file systems bugs is like fixing driver bugs, a freeze doesn't stop that in any way.

Sure yes, I'd like to see the code. If for nothing else than to give it a test spin on a rainy day. And I'm curious about several things.

Sorry I don't agree. reiser4 _may_ get it when it has proved itself ready.

Jens Axboe

Huh? By whom?

<sigh>. I wanted a simple list of things which were (1) features, (2) things which can't go in during a stable series, and (3) had been posted in the last month without resolution.

My hope is that Linus can still freeze, but exempt any which he feels are worthwhile, since some of them are fairly invasive and take some care to coordinate (hence have missed out in the last month).

I think I'll keep my own list, thanks.
Rusty.

   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

The name in parentheses after the list. Posted to linux-kernel with some kind of note saying "I want this in 2.5". I've been trying not to make too many judgement calls about the patches themselves. (I know that bloats the list a bit, but I'm only maintaining it for another day at most, probably less.)

He'll do that anyway. I'm just trying to put together a list so he can explicitly turn everything he doesn't want down rather than just losing it in the suffle.

I'd be amazed if even half of this list makes it in. It's quite possible none of it will.

Sure thing.

Rob

http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, 
CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?

How about not duplicating Rusty's list. The way you have the Kprobes stuff listed for example could disuade Linus from including it. Only the base kprobe patch was submitted, the rest were posted out of kindness for those of us playing with it. I'd hate to see the number of patches work against it (especially since I requested the extra patches.)

Skip

The "huge disorganized heap 'o patches" thing was an attempt to get Rusty to post some kind of description or announcement for the patches (and I believe has been in the last three or four versions unchanged), but if those either aren't being pushed for 2.5, or he wants to do it himself and doesn't want them to be on my list, I'm fine with that...

The IBM guys asked me to put kprobes on my list. The relationship between kprobes and dprobes is something I had to ask about two or three times before getting particularly clear on (since I don't use it), and what I have links to is what they told me.

I have yet to see Linus complain that a change has been been broken into too many pieces for him. :)

Rob

http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad, 
CmdrTaco, liquid nitrogen ice cream, and caffienated jello.  Well why not?