Re: My Wishlist and strategic thinking for v2.4

[David Weinehall <tao@acc.umu.se>]

On Fri, 29 Jan 1999, Matthew Kirkwood wrote:

> 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.

Seems to bug out for most other people...
 
> > 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..."[*]

Yup, I think this depends mostly on it not being included in the maintree.
Most of the releases have just been "ported to v2.1.1xxx" releases.
 
> 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[**].

See below.
 
> [*] 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..

You don't grasp the idea of a devfs, I think. The meaning with a devfs is
to manage your devices in a such way that you can figure out where they
are located in the system. For instance, sdg5 isn't of much use if you
have a device in the chain that is removable, etc. The extra info devfs
brings can make the whole change if you want to locate what disk or device
is making the trouble on a large server with 100's of disks, several
RAID-systems, etc.


> > 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 :)

ok...
 
> > o LVM
> > o Full Large Disk/Userspace/Process/File etc. support
> 
> Would be nice.  Not that I'd have a use for them :)

Me neither, I would manage with < 2 GB support and 16 users or so...
 
> > And for the mainstream users:
> > o Completely new xconfig and rewritten configure/menuconfig with
> >   warning-messages
> 
> Michael Chastain is working on this.

Yup, I know.
 
> > And miscellaneous:
> > o A new thought-through and consistent sound-driver interface (work in
> >   progress?)
> 
> Indeed.  And looking pretty good.

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).

The reason to split /proc and /kern is for structure and purity. Oh, and I
could go along with having both kernfs, procfs & sysfs... I don't think
the overhead would be very big; they could share much code.

/David Weinehall
  _                                                                 _ 
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\ 
//  Project MCA Linux hacker        //  Dance across the winter sky // 
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </ 

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