January 17, 2001

I've seen several times on this list people wondering what features were in the works for 2.5 and what the status of the development was. I did some grepping on the archive and put together a list of things that have been discussed / worked on for 2.5 over the past year or so.

It's probably pretty incomplete and full of errors at this point but I'll be happy to update it if you send me email.

o Merged   New scheduler for improved scalability       (Ingo Molnar)
o Merged   Rewrite of the block IO (bio) layer          (Jens Axboe)
o Merged   New kernel device structure (kdev_t)         (Linus Torvalds)
o Merged   Initial support for USB 2.0                  (Greg KH, others)
o Ready    Add User-Mode Linux (UML)                    (Jeff Dike)
o Ready    Add ALSA (Advanced Linux Sound Architecture) (ALSA team)
o Ready    IDE layer update                             (Andre Hedrick)
o <1 month New kernel build system (kbuild 2.5)         (Keith Owens)
o <1 month New kernel config system: CML2               (Eric Raymond)
o Beta     New driver API for Wireless Extensions       (Jean Tourrilhes)
o Beta     New IO scheduler                             (Jens Axboe)
o Beta     Add JFS (Journaling FileSystem from SGI)     (JFS team)
o Beta     New VM with reverse mappings                 (Rik van Riel)
o Beta     Add preempt kernel option                    (Robert Love)
o Beta     Add resheduling points to remove latency     (Andrew Morton)
o Beta     Build option for Linux Trace Toolkit (LTT)   (Karim Yaghmour)
o Beta     Better event logging for enterprise systems  (evlog team)
o Ongoing  Better support of high-end NUMA machines     (NUMA team)
o Alpha    Add Asynchronous IO (aio) support            (Ben LaHaise)
o Alpha    Integrate EVMS into kernel                   (EVMS team)
o Started  Rewrite of the framebuffer layer             (James Simmons)
o Started  New driver model & unified device tree       (Patrick Mochel)
o Started  Rewrite of the console layer                 (James Simmons)
o Started  More complete NetBEUI and 802.2 net stacks   (Alnaldo C de M)
o Draft #2 New lightweight library (klibc)              (Greg KH)
o Draft #3 Replace initrd by initramfs                  (hpa, Al Viro)
o Planning Change all drivers to new driver model       (All maintainers)
o Planning Add thrashing control                        (Rik van Riel)
o Planning Remove all hardwired drivers from kernel     (Alan Cox, etc)
o Planning Porting all input devices over to input API  (James Simmons)
o Planning generic parameter/command line interface     (Keith Owens)

I hope this is helpful. Enjoy!

-- gb

----------------------------------------
Guillaume Boissiere

I'm sure IBM will be glad you said their FS was done by SGI :) JFS == IBM's toy, XFS == SGI's toy.

// Stefan

You missed the serial.c restructure.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

And the support for CPU clock/voltage scaling. 8-)

Is the ARM side of this ready ? If so, I'll wrap up the remaining x86 bits soon, and we can get this to a bigger audience.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

The basic support is stable. We need to sort out a nicer way to get the memory timing variables, but that's only an initialisation issue we can add later on.

Erik

J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/

Great !!!. I think this "todo list" was much needed. Let me suggest a couple of things that should find their way into 2.5.x sometime in the futute, and that I consider important:
. Generic (VFS layer?) ACL implementation: it seems under heavy
develpment by some groups, and could be something quite interesting to have for 2.6.x
. Linux Security Module (LSM)
. LVM 2: it seems LVM developers are about to release a first version of
the new (version 2.0) LVM (Logical Volume Management) implementation for Linux. Seems to solve the problems current code base has.
. devfs 2: new implementation of Richard Gooch's devfs for Linux. devfs
is a "must have" for some people, and this new code seems to solve everything that people complained about. AFAIR, Richard has submitted several "cuts" of the new code.

There are other interesting things I don't follow as closely, and that could be available when 2.5.x is still under development, maybe not. . reiserfs 4 (later this year): maybe too late for inclusion. . USAGI IPv6 implementation for Linux: maybe not ready for prime time. . NFS v4: have read about it, but don't remember about deadlines. . IPsec in kernel (FreeS/WAN): the neverending story :)

That is what I think are the most important things that _could_ be part of future 2.6.0, should maintainers consider it as a good idea. Please, this is only informative, not trying to "sell" you nothing.

Good work !

José Luis Domingo López
Linux Registered User #189436     Debian Linux Woody (P166 64 MB RAM)
 
jdomingo AT internautas DOT   org  => Spam at your own risk

Yeah, but I don't know if Linus will want it assigned to him.. ;)

t.

*********************************************************
*  tpepper@vato dot org             * Venimus, Vidimus, *
*  http://www.vato.org/~tpepper     * Dolavimus         *
*********************************************************

Well, he said recently that what he was really good at doing what to make the tough decisions for Linux.
Given the controversy about this, this most certainly qualifies!

So I'll add it to the list as is until he complains :-)

-- Guillaume

Followup to:  <[email protected]>
By author:    "Tim Pepper" <[email protected]>
In newsgroup: linux.dev.kernel

Given that he doesn't seem to be willing to let anyone else do it, either...

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

I'm not sure if any of the block changes already include this or if this will rekindle the flamewar on devfs, but something's going to need to happen with device naming.

At the very least the upcoming change to the major/minor allocation will allow large numbers of block devices and fs/partitions/check.c's disk_name() will break. I think a lot of the scsi code's ready to support a large number of devices. It'd be kind of ugly to have it find them and disk_name() give them colliding names or names with odd extended characters.

There's already code out there to allow the sd to find more than 128 devices and I've seen it in use where there are enough luns to cause disk_name() to call them interesting names.

Tim

*********************************************************
*  tpepper@vato dot org             * Venimus, Vidimus, *
*  http://www.vato.org/~tpepper     * Dolavimus         *
*********************************************************

So are you suggesting I add the following task to my list?
o Finalize new device naming convention (Linus Torvalds)

-- Guillaume

Have you heard anything about when Linus intends to code freeze? In my planning I am assuming Sept. 30 is way earlier than 2.6 would ship. I remember how long 2.4 took, and I simply assume 2.6 will be the same. At any rate, there is no way we'll be done earlier than September: it is a deep rewrite. Code looks so much better than the old code...., but it is completely new code.

Hans

If Linus says september freezes in september and ships for christmas I will be most suprised. If he says september freezes the may after and ships the december after that I'd count it normal

Personally I'd really like to see the block I/O stuff straightened out. The neccessary VM bits done, device driver updates and a September freeze. I think it can be done, and I think the resulting kernel will be way way better for people with 1Gb+ of RAM, so much better that its worth making a clear release at that point.

Alan

Let us encourage him to give us some warning, like 60 days of warning. Let us also encourage him to code freeze VM and VFS first not last (I think he agrees with this fortunately). I am not going to say anything about when I would like that freeze to hit, except that we won't be ready before September/October because I am finally able to take the time to do things right in the design and so I will. If he freezes in ~September, we'll have an experimental Reiser4 for him. Or so I fondly hope and vaporize.;-)

What about the zero-copy stuff I keep hearing rumors about? How ready to go is it? We want ReiserFS to be well-integrated with it if possible.

Hans

I recall in June of 1999 Linus gave a kernel talk at BALUG and said he was aiming for a year end release of 2.4 (but I think he meant that year ;) and hoped to get the cycle down towards 6 months. Is that type of timeline still the target?

t.

*********************************************************
*  tpepper@vato dot org             * Venimus, Vidimus, *
*  http://www.vato.org/~tpepper     * Dolavimus         *
*********************************************************

6 months. Never! I think we can do one year. I think this because for 2.5.X we see a bunch of projects working on different things for a long period of time. So it is just a matter of making everything work together.

. ---

   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\

___)=(___/

I think I basically have no idea when 2.6 will ship and no idea when code freeze will hit, so I should work on the code and not worry until it is done.

Hans

Just to add my pet point to the list.

o Alpha Replace old NTFS driver with NTFS TNG driver

Cheers,

Anton

  "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

JFS is by IBM, where as SGI has the XFS journaling file system. Don't ask me which are poised to be included, but i am very sure that SGI doesnt have a JFS team, nor does IBM have a XFS team ;-)

-- Chris

Yes, my mistake. Since each of these filesystems is past v1.0, is there any technical issue (other than taste) that needs to be resolved before they can be integrated?

-- gb

----------------------------------------
Guillaume Boissiere

Em Thu, Jan 17, 2002 at 02:13:11AM -0500, Guillaume Boissiere escreveu:

s/Alnaldo/Arnaldo/g

8)

Good work! I must add:

o Ready Per network protocol slabcache and sock.h cleanup (Arnaldo)
o WIP Per fs slabcache and fs.h cleanup (Daniel/jgarzik)

About the 802.2 net stack: its mostly ready, its being used by the linux-sna folks but I've stopped work on it for a while (Jay is also busy with other things right now) to work on the sock cleanup and on a wireless driver (stopped now for a while, will merge other drivers available for the planet wirefree pcmcia driver) and to help in the BIO scsi drivers conversion front.

About the NetBEUI stack, it mostly works but its not SMP safe and its still not in a good shape IMHO).

I'll probably be submitting the per network protocol slabcache/sock.h cleanup to DaveM RSN.

- Arnaldo

Hi!

Heh, it is merged in -dj kernels. Make this "ready".
Pavel

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Yeap!! I ask all maintainers that deal with keyboards please port over your keyboad drivers over to the input API. In the near future the console system will be moving to use only the input api.