Messages in this thread | | | Date | Mon, 19 Jan 1998 09:02:21 -0500 (EST) | From | linux kernel account <> | Subject | Re: 3.0 wishlist Was: Overview of 2.2.x goals? |
| |
On Mon, 19 Jan 1998, James Mastros wrote:
> 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 >
| |