Re: 3.0 wishlist Was: Overview of 2.2.x goals?

James Mastros (
Mon, 19 Jan 1998 02:36:15 -0500 (EST)

On Mon, 19 Jan 1998, linux kernel account wrote:
> I suggest 3.0 be released once all the below are accomplished, many of
> them already are but they need to be stable and around long enough to have
> userspace utils..
> * Ext2fs (call it ext3 perhaps) improvements:
> * Room in inode for 64-bit files
> * Room in inode for 64-bit times (ctime/mtime/ possibly drop atime)
What for? Milisecond acuracy is good enough. Drop atime? Why not ctime?
atime is useful for deciding what to move to archival storage/compress.
> * Room and Implimentation of acls (actual use of as a compiletime module)
> * Room and Implimentation of compression (again a compiletime option)
OK. This, I think, should go in soonish, along with cleaning up the
ppp/rdimage/etc compression drivers.
> * Prehaps a little more cleaverness for directories (faster lookups
> would be nice).
> * An alternate FS, (can be beta)
> * Faster operation would be nice (see reiserfs)
> * Faster checking (supposidly this will also happen in reiserfs eventually)
> * Needn't be as mature as ext2 (can be a expirmental option)
OK... I don't see having expermental fses in a stable tree as very good,
> * R/W ntfs would be of use to many people.
That might not be doable. According to the comments in the ntfs source, it
is based largely on guesswork. Guesswork is fundementaly unsafe.
> * VFS Changes
> * Support for 64-bit file operations. The actual use of 64-bit file
> stuff (other then the inode space) should be an option.
> * a set of open flags to provide the equivlient of raw devices:
> I.e. i_sync, o_sync, o_ordered (no read caching, no write caching,
> and do it without reordering).. It would be nice to have this work
> on both files and block devices (for multimedia on files, and for
> formating and stupid DBMS on block devices).
Changing the kernel's cache behivior (including turning it off) may not be
easy, but it is at least fundementaly possible. Keeping the phisical device
from caching isn't so easy.
> * Coda/KAutomounter
> * Networking changes
> * Full IPV6 (is the standard set it stone yet?)
I don't think it is.
> * Packet scheduling
Done, I think.
> * Improved NAT
> * All fancy ipv4 stuff (nat, firewall, scheduling) ported to IPV6
Most of that should be protocol-independent.
> * Some form of IPV4 -> IPV6 masq.
Part of the IPv6 spec.
> * Support more ISDN adaptors.
If you can get documentation, I'm shure sombody would be more then willing
to write a driver.
> * Some kind of kernel interface to make high performance encrypted
> vpn possible
Same as the last one. However, encription can't be in the kernel proper
because of iditoic US export restrictions. (Do somthing about it:
> * Ipsec would be nice too
I don't think the spec is finished yet.
> * Ethernet load balencing (I've seen stuff to do that)
> * GGI support (evstack!) config option.
Not gonna happen in 2.2... 2.3, possibly.
> * Either in-kernel support for enough PNP to boot a system with
> a isa pnp boot device, or a viable userspace solution (like an improved
> boot loader, initramdisks that must be rebuilt really dont cut it)
You always could boot from an isapnp boot dev, so long as your BIOS supports
plug 'n play.
> * USB+Firewire support
Firewire I would be surprised happening in any real way till 1999.
> * Sound code cleanup (Alan Cox said this was planned for 2.3)
Will happen shortly, I hope.
> * Repair broken scsi naming (Devfs looks good so far)
I don't think devfs will be mainstreem for quite some time.
> * Core Kernel Changes
> * SMP IRQ balencing (we dont do this yet)
I think we do on everything but x86.
> * More/smarter use of spinlocks (networking code?)
This should be doable.
> * Memory fragmentation Protection
> * Pageable Pagetables?
> * SHM improvements.
I don't think these are going to come soon.
> * Possibly DIPC integration, at least some of the
> clustering features that arn't WAY out there. (support
> for a daemon providing shared pid space)
Not hard to add as a patch, and I think it's going to stay that way till we
see some standard for DIPC. (BTW -- DIPC != clustering -- Distributed
Interprocess Communication)
> * Anti-exec-stack option
Long overdue.

> Adding all these things will take a long time.. But thats good, I'm hoping
> that the release of 3.0 will coenside with several userspace events:
These are all userspace events. Linus has no control over them, and they
should have no control over him.

> * libc6/glibc maturing (I was hoping for the interduction of glibc in 2.2
> kernel based distributions, but 2.2 has come a bit late for that.. Right
> now many things to work quite right with glibc (at least out of the box
> they dont) in awhile things will, perhaps this will coenside with 3.0)
It looks mature to me. Most things that are broken are the fault of the
kernel includes for mixing __kernel_foo_t and foo_t, and the aplication for
using kernel interfaces instead of libc's (more stable) interface.

> * pgcc features into the mainstream compiler.
Done. If you havn't heard, gcc 2.8 is out.

> * Widespread userspace libggi support.
Not going to happen untill GGI goes mainstreem. GGI can emulate X and
Svgalib, so most apps won't see the difference.

> * DOSEMU that can run win3.1 in a xwindow mostly out of the box (almost
> there, when will they declare 1.0??), dosemu on non-x86 (that has just
> started)..
Well, win3.1 in real mode. Windows in extened mode simply isn't possible...
it wants to controll things that Linux needs to controll. It simply dosn't
play fair.

One thing here that might have to do with the kernel is a generic emulation
service. IE let userspace handle the invalid instruction fault.

> With these and the above kernel 3.0, you have ....the operating system of
> the future.... :)
The kernel itself dosn't create a whole OS. You need a lot of userspace
programs on top of it. Remember that you are posting to the kernel list.

-=- James Mastros