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
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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
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
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
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 *
> *********************************************************
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
On Thu 17 Jan at 17:22:46 -0500 [email protected] 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 *
*********************************************************
On Fri 18 Jan at 01:21:56 +0300 [email protected] 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 *
*********************************************************
> > 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!!!!
(| | )
/'_ _/`\
___)=(___/
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 [email protected]
>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/
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
>
>
>> 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
> 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
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
> 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
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 [email protected] 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 *
> *********************************************************
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
Followup to: <[email protected]>
By author: "Tim Pepper" <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Thu 17 Jan at 17:22:46 -0500 [email protected] 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
--
<[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]>
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.
> 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.