Re: My Wishlist and strategic thinking for v2.4

[Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>]

On Fri, 29 Jan 1999, David Weinehall wrote:

> For us hackers/admins/bofh's or whatever:
> o Read/Write NTFS & HPFS
> o Read/Write FFS
> o Read/Write XFS
> o Support for the file-systems in Digital Unix/AIX/Solaris etc.
> o Read/Write VMS file-system (No, I don't know what kind of filesystem it
>   is)

Fair.

> o Working VFAT

Works for me.  UVFAT might be nice, though.

> o NFS v3 (no sane network administrator would possibly want to downgrade
>   from NFS v3 to NFS v2)

Hopefully we'll see this completed and merged in 2.3.

> o DevFS (I think it really deserves to get in as soon as possible; Richard
>   Gooch has made a brilliant job with it)

Personally, I'd rather we went to 32- (even 64-)bit kdev_t and had a
dumbfs which could only hold device nodes until ext2 and reiserfs support
it.  It also concerns me that there have been ~88 releases of devfs and at
least a third of them have included in the release notes a line like
"Fixed a (bug|leak|NPD) where..."[*]

I played with it briefly and it looked alright, but until it adequately
solves the "persistant permissions" problem, it is of no use to me[**].

[*] I'm prepared to accept that this is as much due to /not/ being in the
    mainstream kernel as anything else.

[**] And I'm aware that Linux is of no use to people who want partitioned
     RAID devices, >16 partitions, >64 disks, &c, &c.  I just think that
     32- or 64-bit device numbers are the wy to go..

> o ReiserFS

A very nice piece of work.  I've had a couple of crashes, but I'm
sufficiently happy with it that it holds my /opt partition :)

> o LVM
> o Full Large Disk/Userspace/Process/File etc. support

Would be nice.  Not that I'd have a use for them :)

> And for the mainstream users:
> o Completely new xconfig and rewritten configure/menuconfig with
>   warning-messages

Michael Chastain is working on this.

> And miscellaneous:
> o A new thought-through and consistent sound-driver interface (work in
>   progress?)

Indeed.  And looking pretty good.

> o Moving all the crap out of /proc (/proc should be processes, nothing
>   else) and into a new directory (/kernel /system or similar). That
>   file-system should be a separate compile-time option

Hmm.. BSD splits /proc and /kern, and I don't really see the point.  If
you were doing that ,then you'd probably want kernfs (interrupts, cpuinfo,
&c) and sysfs (for the /proc/sys stuff).

Matthew.

-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/