[STATUS 2.5] January 18, 2002

[STATUS 2.5] January 18, 2002

[Guillaume Boissiere]

Here is a new and improved list, thanks to all the great feedback I have 
received from dozens of people.  Again, if there are any inaccuracies,
please let me know and I will do my best to correct it for next week.

For everyone's enjoyment, I have also put an online version, (with 
hyperlinks, yeah!) at:
http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html 

Items in bold are new since last time.  Also, to avoid having the list
become too big over time, I have decided that I will only accept items 
that can be expected to be merged within the next 6 months (i.e. the 
end of June).

Enjoy!

-- Guillaume

-------------------------------------------------------------
Kernel 2.5 status  -  January 18th, 2002

Features:

o Merged     New scheduler for improved scalability        (Ingo Molnar, Davide Libenzi)
o Merged     Rewrite of the block IO (bio) layer           (Jens Axboe)
o Merged     New kernel device structure (kdev_t)          (Linus Torvalds, etc)
o Merged     Initial support for USB 2.0                   (David Brownell, Greg Kroah-Hartman, 
others)
* Pending    IDE layer update                              (Andre Hedrick)
* Pending    Finalize new device naming convention         (Linus Torvalds)
o Ready      Add User-Mode Linux (UML)                     (Jeff Dike)
* Ready      HDLC (High-level Data Link Control) update    (Krzysztof Halasa)
o Ready      Add ALSA (Advanced Linux Sound Architecture)  (ALSA team)
o <1 month   New kernel build system (kbuild 2.5)          (Keith Owens)
o <1 month   New kernel config system: CML2                (Eric Raymond)
* Beta       Add support for CPU clock/voltage scaling     (Erik Mouw, Dave Jones, Russell King, 
Arjan van de Ven)
* Beta       Serial driver restructure                     (Russell King)
o Beta       New driver API for Wireless Extensions        (Jean Tourrilhes)
o Beta       New IO scheduler                              (Jens Axboe)
* Beta       NAPI Network interrupt mitigation             (Jamal Hadi Salim, Robert Olsson, Alexey 
Kuznetsov)
o Beta       Add JFS (Journaling FileSystem from IBM)      (JFS team)
* Beta       Add XFS (A journaling filesystem from SGI)    (XFS 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)
* Alpha      Overhaul PCMCIA support                       (David Woodhouse, David Hinds)
* Alpha      Replace old NTFS driver with NTFS TNG driver  (Anton Altaparmakov)
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    (Arnaldo Carvalho de Melo)
o Draft #2   New lightweight library (klibc)               (Greg Kroah-Hartman)
o Draft #3   Replace initrd by initramfs                   (H. Peter Anvin, 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)

Cleanups:

* Ready      Per network protocol slabcache & sock.h       (Arnaldo Carvalho de Melo)
* Beta       file.h and INIT_TASK                          (Benjamin LaHaise)
* Started    Per filesystem slabcache & fs.h               (Daniel Phillips, Jeff Garzik)

Re: [STATUS 2.5] January 18, 2002

[Tomasz Kłoczko]

On Fri, 18 Jan 2002, Guillaume Boissiere wrote:
[[.]]
> 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)

Is someone planing cleanup current ipv4 for allow modularize ?

It will be good have abilities for allow prepare (dist) kernel binaries
with modular ipv4 and ipv6 for allow on run-time choose which protocol
will be main (or even ipx or any other protocol) without recompile all
suff.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

Re: [STATUS 2.5] January 18, 2002

[Jens Axboe]

On Fri, Jan 18 2002, Guillaume Boissiere wrote:
> * Pending    IDE layer update                              (Andre Hedrick)

As of 2.5.3-pre1, IDE updates have been merged.

-- 
Jens Axboe

Re: [STATUS 2.5] January 18, 2002

[hjb]

>For everyone's enjoyment, I have also put an online version, (with 
>hyperlinks, yeah!) at:
>http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html 

Nice, but could you give it a permanent URL, like latest.html or index.html?

Thanks,
hjb
-- 
Pro-Linux - Germany's largest volunteer Linux support site
http://www.pro-linux.de/          Public Key ID 0x3DDBDDEA

Re: [STATUS 2.5] January 18, 2002

[Russell King]

On Fri, Jan 18, 2002 at 08:53:27AM +0100, hjb@pro-linux.de wrote:
> >For everyone's enjoyment, I have also put an online version, (with 
> >hyperlinks, yeah!) at:
> >http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html 
> 
> Nice, but could you give it a permanent URL, like latest.html or index.html?

Also it might be a good idea to add the kernel version it refers to at
the top.

-- 
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 18, 2002

[Alan Cox]

You seem to be short

NetBEUI network stack			Arnaldo Carvalho de Melo (from
					Procom donated code)

Re: [STATUS 2.5] January 18, 2002

[Arnaldo Carvalho de Melo]

Em Fri, Jan 18, 2002 at 10:20:29AM +0000, Alan Cox escreveu:
> You seem to be short
> 
> NetBEUI network stack			Arnaldo Carvalho de Melo (from
> 					Procom donated code)

Right, the 802.2 code as well

Re: [STATUS 2.5] January 18, 2002

[Arnaldo Carvalho de Melo]

Em Fri, Jan 18, 2002 at 01:09:51PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jan 18, 2002 at 10:20:29AM +0000, Alan Cox escreveu:
> > You seem to be short
> > 
> > NetBEUI network stack			Arnaldo Carvalho de Melo (from
> > 					Procom donated code)
> 
> Right, the 802.2 code as well

Also please put the 802.2 stack in another line because Jay Schullist is
working with me in this and has contributed the support for PF_LLC sockets,
as the procom code had 802.2 available only for higher level protocols,
with Jay's work it is now possible to use 802.2 sockets from userspace.

- Arnaldo

Re: [STATUS 2.5] January 18, 2002

[Alexander Viro]

On Fri, 18 Jan 2002, Guillaume Boissiere wrote:

> o Merged     New scheduler for improved scalability        (Ingo Molnar, Davide Libenzi)
> o Merged     Rewrite of the block IO (bio) layer           (Jens Axboe)
> o Merged     New kernel device structure (kdev_t)          (Linus Torvalds, etc)
> o Merged     Initial support for USB 2.0                   (David Brownell, Greg Kroah-Hartman, 

Merged: Per-process namespaces, late-boot cleanups.
Ready: switch to ->get_super() as primary file_system_type method.
Ready: ->getattr() handling and changes of ->setattr()/->permission()
prototypes.
Pending: proper UFS fixes, ext2 cleanups and locking
changes.
Pending: per-mountpoint read-only, union-mounts and unionfs.
Pending: lifting limitations on mount(2)
In progress: killing kdev_t for block devices (switch to struct block_device *)
Started: UMSDOS rewrite (the damn thing blocks struct inode trimming)
Planned: new mount API.

Re: [STATUS 2.5] January 18, 2002

[Andrew Morton]

Alexander Viro wrote:
> 
> On Fri, 18 Jan 2002, Guillaume Boissiere wrote:
> 
> > o Merged     New scheduler for improved scalability        (Ingo Molnar, Davide Libenzi)
> > o Merged     Rewrite of the block IO (bio) layer           (Jens Axboe)
> > o Merged     New kernel device structure (kdev_t)          (Linus Torvalds, etc)
> > o Merged     Initial support for USB 2.0                   (David Brownell, Greg Kroah-Hartman,
> 
> Merged: Per-process namespaces, late-boot cleanups.
> Ready: switch to ->get_super() as primary file_system_type method.
> Ready: ->getattr() handling and changes of ->setattr()/->permission()
> prototypes.
> Pending: proper UFS fixes, ext2 cleanups and locking
> changes.
> Pending: per-mountpoint read-only, union-mounts and unionfs.
> Pending: lifting limitations on mount(2)
> In progress: killing kdev_t for block devices (switch to struct block_device *)
> Started: UMSDOS rewrite (the damn thing blocks struct inode trimming)
> Planned: new mount API.

Please can we provide some way for filesystems to know whether
a whole-fs sync() is happening?

At present, ext3_write_super() doesn't know whether it's called
on the kupdate path (where waiting on I/O completion is inappropriate)
or on the sys_sync() path (where it is appropriate).

I think super_operations.sync(struct super_block *sb, int wait)
is an appropriate way to do this.

In fact the whole synchronous-operation thing is a bit of a
twisty mess at present.  There are several places where
ext3 has to use magical intuition to work out which part of
the kernel is calling it in which mode and why.

Note how ext3_file_write() calls mark_inode_dirty() if the
write in synchronous, just to ensure that generic_file_write()
will later call generic_osync_inode().  blech.  This took
some time to sort out, and is fragile.

-

Re: [STATUS 2.5] January 18, 2002

[Ville Herva]

Alexander Viro wrote:
> 
> Merged: Per-process namespaces, late-boot cleanups.
> Ready: switch to ->get_super() as primary file_system_type method.
> Ready: ->getattr() handling and changes of ->setattr()/->permission()
> prototypes.
> Pending: proper UFS fixes, ext2 cleanups and locking
> changes.
> Pending: per-mountpoint read-only, union-mounts and unionfs.
> Pending: lifting limitations on mount(2)
> In progress: killing kdev_t for block devices (switch to struct block_device *)
> Started: UMSDOS rewrite (the damn thing blocks struct inode trimming)
> Planned: new mount API.

All this seems very neat. One question: what about forced umount / forced
remount readonly stuff? Any plans on that?


-- v --

v@iki.fi

Re: [STATUS 2.5] January 18, 2002

[Jakob Østergaard]

On Sat, Jan 19, 2002 at 08:43:00PM +0200, Ville Herva wrote:
> Alexander Viro wrote:
> > 
> > Merged: Per-process namespaces, late-boot cleanups.
> > Ready: switch to ->get_super() as primary file_system_type method.
> > Ready: ->getattr() handling and changes of ->setattr()/->permission()
> > prototypes.
> > Pending: proper UFS fixes, ext2 cleanups and locking
> > changes.
> > Pending: per-mountpoint read-only, union-mounts and unionfs.
> > Pending: lifting limitations on mount(2)
> > In progress: killing kdev_t for block devices (switch to struct block_device *)
> > Started: UMSDOS rewrite (the damn thing blocks struct inode trimming)
> > Planned: new mount API.
> 
> All this seems very neat. One question: what about forced umount / forced
> remount readonly stuff? Any plans on that?
> 

That would be *very* nice indeed.  Even if it was only for things like NFS
and SMBFS.

And even if it is unsafe - it's a lot better to be able to say "screw those
pending writes", than to have to say "screw the pending writes by rebooting the
system".

Just my 0.02 Euro

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: [STATUS 2.5] January 18, 2002

[Ville Herva]

On Sat, Jan 19, 2002 at 11:24:55PM +0100, you [Jakob Østergaard] claimed:
>
> That would be *very* nice indeed.  Even if it was only for things like NFS
> and SMBFS.
> 
> And even if it is unsafe - it's a lot better to be able to say "screw
> those pending writes", than to have to say "screw the pending writes by
> rebooting the system".

Last time this was discussed on the list, Tigran Aivazian mentioned this
patch:

http://www.moses.uklinux.net/patches/forced-umount-2.4.9.patch

I haven't tested it, but it seems better than "fuser -k -m /fs" (and the
problem I've faced is that if there's something wrong (like HW level IO
problems) kill -KILL won't work).


-- v --

v@iki.fi

Re: [STATUS 2.5] January 18, 2002

[Alexander Viro]

On Sat, 19 Jan 2002, [iso-8859-1] Jakob ьstergaard wrote:

> > All this seems very neat. One question: what about forced umount / forced
> > remount readonly stuff? Any plans on that?
> > 
> 
> That would be *very* nice indeed.  Even if it was only for things like NFS
> and SMBFS.

umount(mountpoint, MNT_DETACH);

Had been there for quite a while...

It's not a forced umount - it detaches the subtree from mountpoint and
filesystem(s) go away when they stop being busy.  But for remote
filesystems that's precisely what you want.

Re: [STATUS 2.5] January 18, 2002

[Pavel Machek]

Hi!

> > > All this seems very neat. One question: what about forced umount / forced
> > > remount readonly stuff? Any plans on that?
> > > 
> > 
> > That would be *very* nice indeed.  Even if it was only for things like NFS
> > and SMBFS.
> 
> umount(mountpoint, MNT_DETACH);
> 
> Had been there for quite a while...
> 
> It's not a forced umount - it detaches the subtree from mountpoint and
> filesystem(s) go away when they stop being busy.  But for remote
> filesystems that's precisely what you want.

Can I umount filesystems below them? Can I reboot with
busy-but-detached filesystems? Can I kill the processes accessing busy
filesystems? [That was big point of force umount, I believe.]
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [STATUS 2.5] January 18, 2002

[Alexander Viro]

On Wed, 23 Jan 2002, Pavel Machek wrote:

> > It's not a forced umount - it detaches the subtree from mountpoint and
> > filesystem(s) go away when they stop being busy.  But for remote
> > filesystems that's precisely what you want.
> 
> Can I umount filesystems below them?

Entire subtree gets umounted.  Stuff that isn't busy gets shut down
immediately, the rest - when it stops being busy.

> Can I reboot with
> busy-but-detached filesystems?

You can, but if they are local you'll get dirty shutdown (if they are still
busy at the time of reboot).

> Can I kill the processes accessing busy
> filesystems? [That was big point of force umount, I believe.]

Huh?  If process is killable - it's killable.  What does it have to
--force?

force umount [was Re: [STATUS 2.5] January 18, 2002]

[Pavel Machek]

Hi!

> > Can I kill the processes accessing busy
> > filesystems? [That was big point of force umount, I believe.]
> 
> Huh?  If process is killable - it's killable.  What does it have to
> --force?

Following situation used to be common and "not a bug":

process a tries to read /nfs/foo, but nfs server dies.

kill -9 a does not kill a.

It used to be "not a bug" before. Can we declare it a bug after umount
/nfs --force?
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: force umount [was Re: [STATUS 2.5] January 18, 2002]

[Denis Vlasenko]

> > > Can I kill the processes accessing busy
> > > filesystems? [That was big point of force umount, I believe.]
> >
> > Huh?  If process is killable - it's killable.  What does it have to
> > --force?
>
> Following situation used to be common and "not a bug":
>
> process a tries to read /nfs/foo, but nfs server dies.
>
> kill -9 a does not kill a.
>
> It used to be "not a bug" before. Can we declare it a bug after umount
> /nfs --force?

After more than a year on lkml I still don't understand why it's not a bug.
Anyway, I always mount NFS with hard,intr and my processes are killable...
--
vda

Re: [STATUS 2.5] January 18, 2002

[Alexander Viro]

On Wed, 23 Jan 2002, Pavel Machek wrote:

> Can I umount filesystems below them?

If you mean filesystem it had been mounted on - sure.  Mountpoint is
not busy anymore.

Re: [STATUS 2.5] January 18, 2002

[Dave Jones]

On Fri, 18 Jan 2002, Guillaume Boissiere wrote:

> For everyone's enjoyment, I have also put an online version, (with
> hyperlinks, yeah!) at:
> http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html

Minor nit. Just calling it 'status.html' will allow people to bookmark
it, and check back without needing to guess the date you updated it
last. Also makes it easier for people to link it from kernel related
portals like kerneltrap.com, kernelnewbies.org etc etc..

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

Re: [STATUS 2.5] January 18, 2002

[Eric W. Biederman]

"Guillaume Boissiere" <boissiere@mediaone.net> writes:

> Here is a new and improved list, thanks to all the great feedback I have 
> received from dozens of people.  Again, if there are any inaccuracies,
> please let me know and I will do my best to correct it for next week.
> 
> For everyone's enjoyment, I have also put an online version, (with 
> hyperlinks, yeah!) at:
> http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html 
> 
> Items in bold are new since last time.  Also, to avoid having the list
> become too big over time, I have decided that I will only accept items 
> that can be expected to be merged within the next 6 months (i.e. the 
> end of June).

>From the linuxBIOS project:
Linux booting elf images (aka linux)
   The core is stable and I'm working out some last details of the interface.

First pass at LinuxBIOS support 
   I have code it just needs to fit into the kernel tree.

Eric

Re: [STATUS 2.5] January 18, 2002

[David Weinehall]

On Sun, Jan 20, 2002 at 05:02:29AM -0700, Eric W. Biederman wrote:
> "Guillaume Boissiere" <boissiere@mediaone.net> writes:
> 
> > Here is a new and improved list, thanks to all the great feedback I have 
> > received from dozens of people.  Again, if there are any inaccuracies,
> > please let me know and I will do my best to correct it for next week.
> > 
> > For everyone's enjoyment, I have also put an online version, (with 
> > hyperlinks, yeah!) at:
> > http://people.ne.mediaone.net/boissiere/Status-18-Jan-2002.html 
> > 
> > Items in bold are new since last time.  Also, to avoid having the list
> > become too big over time, I have decided that I will only accept items 
> > that can be expected to be merged within the next 6 months (i.e. the 
> > end of June).
> 
> >From the linuxBIOS project:
> Linux booting elf images (aka linux)
>    The core is stable and I'm working out some last details of the interface.
> 
> First pass at LinuxBIOS support 
>    I have code it just needs to fit into the kernel tree.

Unless it's already in there:

* Sort out which USB UHCI-driver to keep (UHCI or UHCI-JE)


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [STATUS 2.5] January 18, 2002

[Greg KH]

On Sun, Jan 20, 2002 at 01:37:45PM +0100, David Weinehall wrote:
> 
> Unless it's already in there:
> 
> * Sort out which USB UHCI-driver to keep (UHCI or UHCI-JE)

Odds are it will be neither :)
(The uhci.c driver will mutate into a uhci-hcd driver, and then the
uhci.c and usb-uhci.c drivers will go away.)

There's a start of a Linux USB TODO available at:
	http://www.linux-usb.org/2.5_todo.php

It needs to be flushed out and added to, but at least it's a start.

thanks,

greg k-h

Re: [STATUS 2.5] January 18, 2002

[Rick A. Hohensee]

Al The Virile quoted and wroted...

>Libenzi)
>> o Merged Rewrite of the block IO (bio) layer (Jens Axboe)
>> o Merged New kernel device structure (kdev_t) (Linus Torvalds, etc)
>> o Merged Initial support for USB 2.0 (David Brownell, Greg
>>Kroah-Hartman,>
>
>Merged: Per-process namespaces, late-boot cleanups.

Bold. I've been wondering when/if that would go in. Namespaces is the kind
of thing Bell Labs started over from scratch for. Linus merged that? If so
Al is to be congratulated, even if 2.5 never slithers off the labORatory
slab. Don't tell Al I said so***. I applaud namespaces as something very
personable, unlike the "IBM PC", and unlike most concerns of this mailing
list. Namespaces are the kind of thing an open source OS should be doing.
Cheers. Confetti. Good booze.

Here's a little something to keep in mind if namespaces explode on you.
Thier primary claimed benefits are to a user of a distributed operating
system. Note the absence of the term "process" in the previous sentence.
Namespaces (in the Plan 9 sense) are conceptually per user. When you need
to find simplifications, that's where to look.

For example, if I write a kernel, and it ever gets sequestered users, each
user that doesn't live in kernelspace, each "guest", will be one single
process. AmigaDos is one single process in the unix sense, so that's not
as confining as most of you will immediately imagine. That's one AmigaDos
per user. Another way to look at that is as if X and /bin are all shell
built-ins and /usr/bin is scripts. Very performant scripts. Or shell
modules. The guy that wrote the language that C should have remained,
BCPL*, Martin Richards**, is still tweaking the progenitor of AmigaDos,
Tripos, but now it's Cintpos on Linux.

In other words, in a unix context, if namespaces start to eat your head,
consider that they can be quite useful without spanning or surviving a
fork/execve, i.e. they can be useful as per-process-that-can't-fork.
Eunuch process? Note also that emasculating Al's processes would in no
wise compromise his manifest cyberstudmuffinhood.



* BCPL for example might have less problems with dev_t. Cells. See also:
ANSI Forth. 16 or 32 bit, sourcecode-transparently. BCPL is now MCPL
though, with some ML-isms and C-isms. Don't forget to enable shared memory
when looking at Cintpos, to be found at...

** http://www.cl.cam.ac.uk/~mr/

*** if anyone does want to dare to violate the sanctity of Al's
much-ballyhoo'ed killfile, please do .tel him I .sai .tha if he .keep
staring at .thos execve lines in main.c he's going to .star .seein dots.



Rick Hohensee    rickh@capaccess.org    http://linux01.gwdg.de/~rhohen

:; cLIeNUX /dev/tty6  03:47:33   /
:;d -d */
Ha3sm/       command/     floppy/      mounts/      subroutine/
Linux/       configure/   guest/       owner/       suite/
bmgsubs/     dev/         help/        sb/          temp/
boot/        device/      log/         source/
:; cLIeNUX /dev/tty5  03:30:03   /
:;