[STATUS 2.5] January 17, 2001

[STATUS 2.5] January 17, 2001

[Guillaume Boissiere]

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

Re: [STATUS 2.5] January 17, 2001

[Stefan Smietanowski]

Guillaume Boissiere wrote:

> 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 Beta     New IO scheduler                             (Jens Axboe)



> o Beta     Add JFS (Journaling FileSystem from SGI)     (JFS team)

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

// Stefan

Re: [STATUS 2.5] January 17, 2001

[Russell King]

On Thu, Jan 17, 2002 at 02:13:11AM -0500, Guillaume Boissiere wrote:
> 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.  

You missed the serial.c restructure.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [STATUS 2.5] January 17, 2001

[Dave Jones]

On Thu, Jan 17, 2002 at 10:03:30AM +0000, Russell King wrote:
 > You missed the serial.c restructure.

 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

Re: [STATUS 2.5] January 17, 2001

[Erik Mouw]

On Thu, Jan 17, 2002 at 12:21:35PM +0100, Dave Jones wrote:
>  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.

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: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: [STATUS 2.5] January 17, 2001

[Jose Luis Domingo Lopez]

On Thursday, 17 January 2002, at 02:13:11 -0500,
Guillaume Boissiere wrote:

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

Re: [STATUS 2.5] January 17, 2001

[Tim Pepper]

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

Re: [STATUS 2.5] January 17, 2001

[Hans Reiser]

Jose Luis Domingo Lopez wrote:

>
>. reiserfs 4 (later this year): maybe too late for inclusion.
>.
>
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

Re: [STATUS 2.5] January 17, 2001

[Tim Pepper]

On Fri 18 Jan at 01:21:56 +0300 reiser@namesys.com done said:
> Jose Luis Domingo Lopez wrote:
> 
> >
> >. reiserfs 4 (later this year): maybe too late for inclusion.
> >.
> >
> 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. 

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

Re: [STATUS 2.5] January 17, 2001

[James Simmons]

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

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!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

Re: [STATUS 2.5] January 17, 2001

[Hans Reiser]

James Simmons wrote:

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

Re: [STATUS 2.5] January 17, 2001

[Alan Cox]

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

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

Re: [STATUS 2.5] January 17, 2001

[Hans Reiser]

Alan Cox wrote:

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

Re: [STATUS 2.5] January 17, 2001

[Guillaume Boissiere]

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

-- Guillaume



On 17 Jan 2002 at 14:14, Tim Pepper wrote:

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

Re: [STATUS 2.5] January 17, 2001

[Tim Pepper]

On Thu 17 Jan at 17:22:46 -0500 boissiere@mediaone.net done said:
> So are you suggesting I add the following task to my list?
> o Finalize new device naming convention (Linus Torvalds)

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

Re: [STATUS 2.5] January 17, 2001

[H. Peter Anvin]

Followup to:  <20020117143016.B11402@vato.org>
By author:    "Tim Pepper" <tpepper@vato.org>
In newsgroup: linux.dev.kernel
>
> On Thu 17 Jan at 17:22:46 -0500 boissiere@mediaone.net done said:
> > So are you suggesting I add the following task to my list?
> > o Finalize new device naming convention (Linus Torvalds)
> 
> Yeah, but I don't know if Linus will want it assigned to him.. ;)
> 

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

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: [STATUS 2.5] January 17, 2001

[Guillaume Boissiere]

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


On 17 Jan 2002 at 14:30, Tim Pepper wrote:

> On Thu 17 Jan at 17:22:46 -0500 boissiere@mediaone.net done said:
> > So are you suggesting I add the following task to my list?
> > o Finalize new device naming convention (Linus Torvalds)
> 
> 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         *
> *********************************************************

Re: [STATUS 2.5] January 17, 2001

[Anton Altaparmakov]

Just to add my pet point to the list.

o Alpha Replace old NTFS driver with NTFS TNG driver

Cheers,

Anton

At 07:13 17/01/02, Guillaume Boissiere wrote:
>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
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
   "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/

Re: [STATUS 2.5] January 17, 2001

[Chris Chabot]

>
>
>> o Beta     Add JFS (Journaling FileSystem from SGI)     (JFS team)
>

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

Re: [STATUS 2.5] January 17, 2001

[Guillaume Boissiere]

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

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

Re: [STATUS 2.5] January 17, 2001

[Arnaldo Carvalho de Melo]

Em Thu, Jan 17, 2002 at 02:13:11AM -0500, Guillaume Boissiere escreveu:
> o Started  More complete NetBEUI and 802.2 net stacks   (Alnaldo C de M)

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

Re: [STATUS 2.5] January 17, 2001

[Pavel Machek]

Hi!

> o Planning Porting all input devices over to input API  (James Simmons)

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.

Re: [STATUS 2.5] January 17, 2001

[James Simmons]

> Hi!
> 
> > o Planning Porting all input devices over to input API  (James Simmons)
> 
> Heh, it is merged in -dj kernels. Make this "ready".

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.