Re: [9fans] Acme mailreader - now: User mode filesystems in linux

[Karl Magdsick <kmagnum@gmail.com>]

> On login, each user starts a user-filesystem-daemon, which uses setuid
> to create a /dev/cfsN, if necessary, opens it to start serving, and
> mounts it on a conventional place: $HOME/mnt, say.

Why are the setuid meta-daemons needed?  You'll want security/sanity
checks within the kernel code anyway, so the main reason for the
setuid meta-daemons is creating(??/destroying??) device files.  It
seems that you could get around this by using one device file for
everyone, which brings us to...

Why N different devices?  The kernel can distinguish between open
filehandles for /dev/cfs and use an array, tree, or map of structs to
keep track of which file handle goes with which mount point.  (Yay,
flyweight design pattern!)  This prevents nastiness with trying to
find an unused device, creating devices on demand, and "garbage
collecting" unused device files.  (You wouldn't want a trillion unused
devices sitting around.)  The kernel can free associated structs when
filehandles close.  Having the meta-daemons garbage collecting unused
device files seems like trouble.
 
> When the user runs a program that wants to serve a filesystem, it attaches to
> the daemon, which creates $HOME/mnt/servicename, and forwards all
> requests for this directory hierarchy to the program. 

As mentioned in another post, you can prevent device files and setuid
executibles in non-root owned filesystems and allow any user process
to mount a fs on any mount point they own.

The kernel needs its own cleanup code (what if one of the per-user
filesystem meta-daemons crashes?) and security/sanity checks (only
allowing root-owned processes to open filehandles to the device).

Granted, using a map of N structs and 1 device instead of N devices
each with 1 struct does increase kernel complexity, but only by a
small amount.  The kernel needs its own security/sanity checks and
cleanup code even in the case of per-user setuid filesystem
meta-daemons.  Setuid per-user filesystem meta-daemons seem like they
would greatly increase user-space complexity (and duplicate
functionality that MUST also be in the kernel) and only minimally
reduce kernel complexity.

Don't get me wrong, I'm a big fan of micro/nanokernels.  I dual booted
BeOS 5 and L4-Linux on my desktop, back when the latest port to L4
user-space was Linux 2.2.(??20??).  I got a warm fuzzy feeling every
time my BeOS flakey 3Com NIC driver crashed and BeOS asked me if I
wanted to restart the network driver.  Buggy drivers weren't so fun,
but a system that easily recovers from driver crashes is just cool! 
(I had a UDFS CD that would cause fs driver crashes in both Linux
(kernel panic) and Win2k (BSOD).  I really wished for user-space fs
drivers on "normal" systems.)  After a few days of 2 L4-Linux system
lock-ups per day, I went back to using Linux as a regular kernel. 
(The diagnostic counters kept spinning, so it seemed that the Linux
server had locked up, not L4, but all of my processes depended on the
Linux server anyway.)

In any case, I'd love to see user-space filesystem (and device)
drivers on mainstream OSes.

I don't have much knowledge of/experience with Plan9, but I've read
that the system is designed so that it's very easy to port drivers
between user-space and kernel-space.  Is this correct?  In a
"standard" setup, how many of the drivers are (mostly) in user-space?


-Karl