From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 17 Dec 2004 09:42:15 -0500 From: Karl Magdsick To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Acme mailreader - now: User mode filesystems in linux In-Reply-To: <20041217152456.3f377069.martin_ml@parvat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3e1162e6041216070874f424e5@mail.gmail.com> <9ccf822edf0a9a77c141ae47312638dd@collyer.net> <20041217102526.0b64d965.martin_ml@parvat.com> <20041217152456.3f377069.martin_ml@parvat.com> Topicbox-Message-UUID: 19fd22e0-eace-11e9-9e20-41e7f4b1d025 > 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