> 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.
Not greater accuracy, room for 2038.. It need not be used yet.. There just
needs to be room..
> > * 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.
Sounds good.
> > * 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,
> however.
There is the expirmental config option..
> > * 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.
Ahh, thats sad.. Welp.. Depending on how long 3.0 takes to come out it
might be possible..
> > * 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.
> Definitly.
> > * 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.
True, most scsi devices have write cache turned off, and it's possible to
disable read caching easily.
> > * Coda/KAutomounter
> Done.
Just because It's included doesn't make it done.. Though, it's mostly
done..
> > * Networking changes
> > * Full IPV6 (is the standard set it stone yet?)
> I don't think it is.
> > * Packet scheduling
> Done, I think.
The source looks neat.. But how do I turn it on? :)
> > * Improved NAT
> Huha?
Ip masq is 1:n nat.. n:n support?
> > * 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:
> www.distributed.net)
I should have made it clearer: a interface so a userspace daemon can
perform encryption would be nice..
As far as distributed net, why not try asking for the sources.. Or am I
the only person left in the world that wont run a forign bin without
sources (esp from some group harnasing cpu to crack des keys, what if
someone hacked their ftp and changed the code to crack my pw file!)
> > * Ipsec would be nice too
> I don't think the spec is finished yet.
> > * Ethernet load balencing (I've seen stuff to do that)
> Done.
> > * GGI support (evstack!) config option.
> Not gonna happen in 2.2... 2.3, possibly.
I hope not 2.2, it's stable!
> > * 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.
Yes, but can you mount root from it?
> > * 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.
Remember all of this I'm refering to for 3.0..
> > * 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)
I know that! But it could be handy for people doing clustering, it makes
programming distributed apps slightly more familar.
> > * Anti-exec-stack option
> Long overdue.
We certantly agree here..
> > 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.
Of course not.. I said hoping.. I'm not asking linux to make it happen..
:)
> > * 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.
I ment the use of them maturing.. this means the apps..
> > * pgcc features into the mainstream compiler.
> Done. If you havn't heard, gcc 2.8 is out.
Really? Cool stuff. It includes the improved scheduling?
> > * 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.
I know that unfortuantly..
> > * 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.
Actually, you can use a bin from WINOS2 (a hacked version of windows from
os2) which is available from some public ftp site.. It actually works..
> 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.
I was just listing userspace things that I would like to see with kernel
3.0.. I know the combenation is whats important..
Just because this is the kernel list, that doesn't mean they should be
blind to the userspace.. Most of the userspace things I mentioned are a
ways off..
> -=- James Mastros
>