Skip to contentSkip to conversation

January 18, 2002

STATUS 2.5 Guillaume Boissiere 17 participants 23 messages Jan 18, 2002 – Jan 24, 2002

lore
Share & tools
lore
#0 lore raw

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)
#1 lore raw

On Fri, 18 Jan 2002, Guillaume Boissiere wrote:
[[.]]

Quoted 5 lines
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

Signature · 4 lines
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
#4 lore raw
In reply to Guillaume Boissiere
Quoted 5 lines · On Fri, Jan 18, 2002 at 08:53:27AM +0100, [email protected] wrote:
Quoted 3 lines

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.

Signature · 2 lines
Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
#6 lore raw
In reply to Guillaume Boissiere
Quoted 4 lines · Guillaume Boissiere
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.

#7 lore raw
In reply to Guillaume Boissiere
Quoted 3 lines · Guillaume Boissiere

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

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
#9 lore raw
In reply to Guillaume Boissiere

Em Fri, Jan 18, 2002 at 01:09:51PM -0200, Arnaldo Carvalho de Melo escreveu:

Quoted 7 lines

Em Fri, Jan 18, 2002 at 10:20:29AM +0000, Alan Cox escreveu:

Quoted 4 lines

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

#10 lore raw
In reply to Guillaume Boissiere
Quoted 8 lines · Alexander Viro
Quoted 4 lines · Guillaume Boissiere
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,
Quoted 11 lines

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.

-

#11 lore raw
In reply to Guillaume Boissiere
Quoted 12 lines · Alexander Viro

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

[email protected]

#12 lore raw
In reply to Guillaume Boissiere
Quoted 14 lines · Ville Herva
Quoted 12 lines · Alexander Viro

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.

Quoted 3 lines

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

Signature · 6 lines
................................................................
:   [email protected]   : 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}...............:
#13 lore raw
Quoted 6 lines · On Sat, 19 Jan 2002, [iso-8859-1] Jakob ьstergaard wrote:
Quoted 3 lines

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.

#14 lore raw
In reply to Jakob Østergaard

Hi!

Quoted 7 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 7 lines

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

Signature · 2 lines
(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
#15 lore raw
Quoted 5 lines · Pavel Machek
Quoted 3 lines

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.

Quoted 2 lines

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

Quoted 2 lines

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?

#17 lore raw

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

In reply to Pavel Machek

Hi!

Quoted 5 lines
Quoted 2 lines

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

Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
#18 lore raw

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

In reply to Pavel Machek
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

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?

Quoted 8 lines

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

#19 lore raw
In reply to Guillaume Boissiere

On Sat, Jan 19, 2002 at 11:24:55PM +0100, you [Jakob Østergaard] claimed:

Quoted 7 lines

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

[email protected]

#20 lore raw
In reply to Guillaume Boissiere
Quoted 8 lines · 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

Quoted 6 lines

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

#21 lore raw
In reply to Guillaume Boissiere
Quoted 15 lines · Eric W. Biederman
Quoted 12 lines · 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).

Quoted 6 lines
Quoted 1 line

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 <[email protected]> /> Northern lights wander \\

//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </
#22 lore raw
In reply to Guillaume Boissiere
Quoted 4 lines · David Weinehall

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