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)
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: [email protected]*
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
>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
On Fri, Jan 18, 2002 at 08:53:27AM +0100, [email protected] 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
You seem to be short
NetBEUI network stack Arnaldo Carvalho de Melo (from
Procom donated code)
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.
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
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.
-
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
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
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 --
[email protected]
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
--
................................................................
: [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}...............:
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 --
[email protected]
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.
"Guillaume Boissiere" <[email protected]> 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
On Sun, Jan 20, 2002 at 05:02:29AM -0700, Eric W. Biederman wrote:
> "Guillaume Boissiere" <[email protected]> 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 <[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 </
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
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
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?
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.
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.
> > > 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