lkml.org 
[lkml]   [1998]   [Jan]   [19]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 19 Jan 1998 09:02:21 -0500 (EST)
Fromlinux kernel account <>
SubjectRe: 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
> 


\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008