2002-10-21 08:57:41

by Rob Landley

[permalink] [raw]
Subject: 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)

>From Karim:

> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html
>
> LTT has seen a number of changes since the posting above. Mainly,
> we've followed the recommendations of quite a few folks from the LKML.
> Here are some highlights summarizing the changes:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103491640202541&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103423004321305&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103247532007850&w=2
>
> The latest patch is available here:
> http://opersys.com/ftp/pub/LTT/ExtraPatches/patch-ltt-linux-2.5.44-vanilla-
>021019-2.2.bz2 Use this patch with version 0.9.6pre2 of the user tools:
> http://opersys.com/ftp/pub/LTT/TraceToolkit-0.9.6pre2.tgz
>
> Karim

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:

> Well, our IPsec is ready, runs and is tested...
> ftp://ftp.linux-ipv6.org/pub/usagi/patch/ipsec/

16) MMU-less processor support.

Greg Ungerer wrote:

>Here's another feature I would like to see go in: MMU-less procesor support.
>
>Latest patches for the memory management changes are at:
>
>http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0-mm.patch.gz
>
>The core of this stuff has been around for years (earliest in 2.0.33),
>with a _lot_ of users (easily > 50000). And specifically these patches
>have been tracking every 2.5 release pretty much since it started.
>
>The other important peice with this is the FLAT format exe loader
>(binfmt_flat), patch at:
>
>http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0-binflat.patch.gz
>
>To make this truely useful though you also need some new archiecture
>support. Up to date patches for 2 of these are at:
>
>http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0-m68knommu.patch.gz
>http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc0-v850.patch.gz
>
>These support the non-VM 68k processors (683XXX and ColdFire), and the
>NEC v850 family. [We have many more (ARM, SPARC, i960, etc) but they are
>not 2.5 ready yet].
>
>Also some drivers to go along with this, but I won't bother listing
>them here. See my other emails on the list for those patches...
>
>Regards
>Greg

======================== 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)

David S. Miller said:

> No URLs, being coded as I type this :-)
>
> Some of the ipv4 infrastructure is in 2.5.44

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

9) Hans Reiser said:

> We will send Reiser4 out soon, probably around the 27th.
>
> Hans

10) Unlimited groups patch

Awaiting URL from Tim Hockin.


2002-10-21 14:41:11

by Jens Axboe

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

On Sun, Oct 20 2002, Rob Landley wrote:
> 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.

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

> 9) Hans Reiser said:
>
> > We will send Reiser4 out soon, probably around the 27th.
> >
> > Hans

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

2002-10-21 15:34:51

by Hans Reiser

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

Jens Axboe wrote:

>
>
>
>>9) Hans Reiser said:
>>
>>
>>
>>>We will send Reiser4 out soon, probably around the 27th.
>>>
>>>Hans
>>>
>>>
>
>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.
>
>
>
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 http://www.namesys.com/v4/fast_reiser4.html for some details on what we
implemented.

Hans

2002-10-21 16:10:33

by Jens Axboe

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

On Mon, Oct 21 2002, Hans Reiser wrote:
[snipped]
> 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.

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.

> 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.;-)

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.

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

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.

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

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

--
Jens Axboe

2002-10-21 16:19:11

by Dan Kegel

[permalink] [raw]
Subject: re: Crunch time continues: the merge candidate list v1.1

Please add epoll to your list.

Latest activity: the author changed the interface at Linus'
request, and made a bunch of fixes at Andrew Morton's request.

Current patch:
http://www.xmailserver.org/linux-patches/sys_epoll-2.5.44-0.3.diff
Home page:
http://www.xmailserver.org/linux-patches/nio-improve.html
Author: Davide Libenzi

Current status: ready to merge, I think...

- Dan

2002-10-28 03:01:13

by Rusty Russell

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

On Sun, 20 Oct 2002 23:03:46 -0500
Rob Landley <[email protected]> wrote:

> but this is what's currently being submitted for consideration.

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

2002-10-28 04:25:45

by Rob Landley

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

On Sunday 27 October 2002 19:29, Rusty Russell wrote:
> On Sun, 20 Oct 2002 23:03:46 -0500
>
> Rob Landley <[email protected]> wrote:
> > but this is what's currently being submitted for consideration.
>
> Huh? By whom?

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

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

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.

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

Sure thing.

> Rusty.

Rob

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

2002-10-28 04:46:47

by Skip Ford

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

Rob Landley wrote:
> On Sunday 27 October 2002 19:29, Rusty Russell wrote:
>
> > I think I'll keep my own list, thanks.
>
> Sure thing.

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

2002-10-28 07:02:01

by Rob Landley

[permalink] [raw]
Subject: Re: Crunch time continues: the merge candidate list v1.1

On Sunday 27 October 2002 23:50, Skip Ford wrote:
> Rob Landley wrote:
> > On Sunday 27 October 2002 19:29, Rusty Russell wrote:
> > > I think I'll keep my own list, thanks.
> >
> > Sure thing.
>
> How about not duplicating Rusty's list.

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

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'd hate to see the number
> of patches work against it (especially since I requested the extra
> patches.)

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?