Whats in the wings for 2.5 (when it opens)

Whats in the wings for 2.5 (when it opens)

[Ed Tomlinson]

Hi,

Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
I can think of:

premptable kernel option
user mode kernel 
jfs
xfs (maybe)
rc2
reverse maping vm
ide driver rewrite
32bit dma
LTT (maybe)
LVM update to 1.01
ELVM (maybe)
module security stuff
UP friendly SMP scheduler

What else?

TIA
Ed Tomlinson

Re: Whats in the wings for 2.5 (when it opens)

[David Weinehall]

On Mon, Sep 17, 2001 at 08:18:25PM -0400, Ed Tomlinson wrote:
> Hi,
> 
> Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> I can think of:
> 
> premptable kernel option
> user mode kernel 
> jfs
> xfs (maybe)

ext3

> rc2
> reverse maping vm
> ide driver rewrite
> 32bit dma
> LTT (maybe)
> LVM update to 1.01
> ELVM (maybe)

I guess you mean EVMS?

> module security stuff
> UP friendly SMP scheduler
> 
> What else?

CML2
KBuild v2.5
^^^
These two are my prio #1.


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Whats in the wings for 2.5 (when it opens)

[James Simmons]

> What else?

Rewrite of the framebuffer layer. 
Porting of all inout devices over to the input api.
Rewrite of the console layer.

Re: Whats in the wings for 2.5 (when it opens)

[Gábor Lénárt]

On Mon, Sep 17, 2001 at 08:18:25PM -0400, Ed Tomlinson wrote:
> Hi,
> 
> Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> I can think of:
> 
> premptable kernel option
> user mode kernel 
> jfs
> xfs (maybe)
> rc2
> reverse maping vm
> ide driver rewrite
> 32bit dma
> LTT (maybe)
> LVM update to 1.01
> ELVM (maybe)
> module security stuff
> UP friendly SMP scheduler

What about:

SCSI layer rewrite
common fs journaling API in kernel
integrating ALSA
and of course clean, fast, etc VM

Sorry if I'm wrong but AFAIK these were planned or at least were mentioned
on this list too ...

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----

Re: Whats in the wings for 2.5 (when it opens)

[toon]

On Mon, Sep 17, 2001 at 08:18:25PM -0400, Ed Tomlinson wrote:
> Hi,
> 
> Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> I can think of:
> 
> premptable kernel option
> user mode kernel 
> jfs
> xfs (maybe)

ext3

> rc2
> reverse maping vm
> ide driver rewrite
> 32bit dma
> LTT (maybe)
> LVM update to 1.01

My opinion is that the LVM update to 1.01 should go into 2.4
as soon as possible.

> ELVM (maybe)
> module security stuff
> UP friendly SMP scheduler
> 
> What else?
> 
> TIA
> Ed Tomlinson

Toon.

Re: Whats in the wings for 2.5 (when it opens)

[Crutcher Dunnavant]

++ 18/09/01 21:49 +0200 - toon@vdpas.hobby.nl:
> On Mon, Sep 17, 2001 at 08:18:25PM -0400, Ed Tomlinson wrote:
> > Hi,
> > 
> > Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> > I can think of:
> > 
> > premptable kernel option
> > user mode kernel 
> > jfs
> > xfs (maybe)
> 
> ext3
> 
> > rc2
> > reverse maping vm
> > ide driver rewrite
> > 32bit dma
> > LTT (maybe)
> > LVM update to 1.01
> 
> My opinion is that the LVM update to 1.01 should go into 2.4
> as soon as possible.
> 
> > ELVM (maybe)
> > module security stuff
> > UP friendly SMP scheduler
> > 
> > What else?
> > 
> > TIA
> > Ed Tomlinson

A cleaner handling of module parameters/cmd line options.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Whats in the wings for 2.5 (when it opens)

[Keith Owens]

On Fri, 21 Sep 2001 15:58:06 -0400, 
Crutcher Dunnavant <crutcher@datastacks.com> wrote:
>A cleaner handling of module parameters/cmd line options.

That comes out as a side effect of kernel build 2.5, every object gets
-DKBUILD_OBJECT to define the name it is known by.  From
Documentation/kbuild/kbuild-2.5.

      -DKBUILD_OBJECT=module, the name of the module the object is
        linked into, without the trailing '.o' and without any paths.
        If the object is a free standing module or is linked into
        vmlinux then the "module" name is the object itself.
        Automatically generated.

Post kbuild 2.5 I will be writing a generic parameter/command line
interface so you can insmod foo bar=99 or boot with foo.bar=99.  You
will even be able to boot with foo.bar=99 when foo is a module, insmod
will use the command line as a default set of values.

Re: Whats in the wings for 2.5 (when it opens)

[Crutcher Dunnavant]

++ 22/09/01 12:59 +1000 - Keith Owens:
> On Fri, 21 Sep 2001 15:58:06 -0400, 
> Crutcher Dunnavant <crutcher@datastacks.com> wrote:
> >A cleaner handling of module parameters/cmd line options.
> 
> That comes out as a side effect of kernel build 2.5, every object gets
> -DKBUILD_OBJECT to define the name it is known by.  From
> Documentation/kbuild/kbuild-2.5.
> 
>       -DKBUILD_OBJECT=module, the name of the module the object is
>         linked into, without the trailing '.o' and without any paths.
>         If the object is a free standing module or is linked into
>         vmlinux then the "module" name is the object itself.
>         Automatically generated.
> 
> Post kbuild 2.5 I will be writing a generic parameter/command line
> interface so you can insmod foo bar=99 or boot with foo.bar=99.  You
> will even be able to boot with foo.bar=99 when foo is a module, insmod
> will use the command line as a default set of values.

Well, that certainly is clean. How deep does it go? For instance, can
we you define it as:

	foo.bar.baz.bat.quux=99 -> mod 'foo.bar.baz.bat', parm 'quux'

so we get naming schemes like:

	net.3com.3c501.i=5

This would help much with keeping some of the namespaces cleaner. Do you
want any help with this?

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Whats in the wings for 2.5 (when it opens)

[Keith Owens]

On Sat, 22 Sep 2001 10:31:00 -0400, 
Crutcher Dunnavant <crutcher@datastacks.com> wrote:
>++ 22/09/01 12:59 +1000 - Keith Owens:
>> Post kbuild 2.5 I will be writing a generic parameter/command line
>> interface so you can insmod foo bar=99 or boot with foo.bar=99.  You
>> will even be able to boot with foo.bar=99 when foo is a module, insmod
>> will use the command line as a default set of values.
>
>Well, that certainly is clean. How deep does it go?

One level, flat.  Module names must be unique, -DKBUILD_OBJECT runs off
module names.

Re: Whats in the wings for 2.5 (when it opens)

[Crutcher Dunnavant]

++ 23/09/01 00:44 +1000 - Keith Owens:
> On Sat, 22 Sep 2001 10:31:00 -0400, 
> Crutcher Dunnavant <crutcher@datastacks.com> wrote:
> >++ 22/09/01 12:59 +1000 - Keith Owens:
> >> Post kbuild 2.5 I will be writing a generic parameter/command line
> >> interface so you can insmod foo bar=99 or boot with foo.bar=99.  You
> >> will even be able to boot with foo.bar=99 when foo is a module, insmod
> >> will use the command line as a default set of values.
> >
> >Well, that certainly is clean. How deep does it go?
> 
> One level, flat.  Module names must be unique, -DKBUILD_OBJECT runs off
> module names.

Yes, but can module names contain periods? If they can, then there can
be a notional heirarchy, and that's really all that's needed.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Whats in the wings for 2.5 (when it opens)

[Arnaldo Carvalho de Melo]

Em Fri, Sep 21, 2001 at 03:58:06PM -0400, Crutcher Dunnavant escreveu:
> ++ 18/09/01 21:49 +0200 - toon@vdpas.hobby.nl:
> > On Mon, Sep 17, 2001 at 08:18:25PM -0400, Ed Tomlinson wrote:
> > > Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> > > I can think of:
> > > premptable kernel option
> > > user mode kernel 
> > > jfs
> > > xfs (maybe)
> > ext3
> > > rc2
> > > reverse maping vm
> > > ide driver rewrite
> > > 32bit dma
> > > LTT (maybe)
> > > LVM update to 1.01
> > My opinion is that the LVM update to 1.01 should go into 2.4
> > as soon as possible.
> > > ELVM (maybe)
> > > module security stuff
> > > UP friendly SMP scheduler
> > > What else?

NetBEUI and more complete 802.2 net stacks, patches available at my work in
progress area at http://bazar.conectiva.com.br/~acme/patches/wip and at my
CVS repository at http://cvs.conectiva.com.br/kernel-acme.

- Arnaldo

Re: Whats in the wings for 2.5 (when it opens)

[José Luis Domingo López]

On Monday, 17 September 2001, at 20:18:25 -0400,
Ed Tomlinson wrote:

> Hi,
> 
> Seems like there is a lot of code "ready" for consideration in a 2.5 kernel.
> I can think of:
> [...]
>
Maybe this is something worth to have a look at:
http://evlog.sourceforge.net/

It seems to be an "enterprise-class advanced event logging system for
Linux", trying toi be compliant with upcoming POSIX Standard 1003.25,
"System API - Services for Reliable, Available, and Serviceable Systems".

It requires kernel patches and userspace logging daemon to work. Kernel
patches are available for 2.4.4 and as I can see from the kernel patch, it
is little intrusive (hardly any changes to existing kernel code, and adds
a couple of new files). It also requires a patched glibc, but the required
patch (for glibc2.2.3) is very little.

--
José Luis Domingo López
Linux Registered User #189436     Debian Linux Woody (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

RE: Whats in the wings for 2.5 (when it opens)

[Grover, Andrew]

unified device tree (for power management)
changing all drivers to support the above.

This stuff isn't the kind of thing that's ready to go beforehand - we need
to get the device tree infrastructure in place, and then we can attack the
drivers.

Regards -- Andy

> From: Ed Tomlinson [mailto:tomlins@cam.org]
> Seems like there is a lot of code "ready" for consideration 
> in a 2.5 kernel.
> I can think of:
> 
> premptable kernel option
> user mode kernel 
> jfs
> xfs (maybe)
> rc2
> reverse maping vm
> ide driver rewrite
> 32bit dma
> LTT (maybe)
> LVM update to 1.01
> ELVM (maybe)
> module security stuff
> UP friendly SMP scheduler
> 
> What else?
> 
> TIA
> Ed Tomlinson