From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Fri, 10 Aug 2007 10:32:41 -0600 From: "Latchesar Ionkov" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] 9P vs. FUSE In-Reply-To: <13426df10708100851i7a385abbx2aa8e83ec32ff74b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070810114225.GF18939@nibiru.local> <2d66a95ea087868174cfdc519a48a2d7@9netics.com> <20070810123336.GG18939@nibiru.local> <13426df10708100851i7a385abbx2aa8e83ec32ff74b@mail.gmail.com> Topicbox-Message-UUID: a4782074-ead2-11e9-9d60-3106f5b1d025 It is not that hard to create few setuid helper programs that make Linux support Plan9-like private namespaces. The union mount would be tricky, is unionfs accepted in the standard kernel yet? Thanks, Lucho On 8/10/07, ron minnich wrote: > On 8/10/07, Eric Van Hensbergen wrote: > > > > > However, it was decided at the last IWP9 that we had probably taken > > the wrong approach with 9p2000.u and it would probably have been > > better to extend 9p with new operations that had different > > syntax/semantics from standard 9p as these would be easier to filter > > out. > > And, before anyone jumps on this idea too hard, this approach works; > it's how I solved this messy problem in 1998. It was well worth trying > the .u variant, however, as you can't know some things until you try > them :-) > > > It was further suggested by some that a better approach on Linux/UNIX > > would have been to take what we know from 9p and design a protocol > > specific to the VFS (similar to FUSE but capable of transparent > > network, etc.) > > That's probably true. What's weird is the first one I did (for 2.0.3x) > fit into Linux VFS layer just fine. That's because the Linux VFS was > not as "mature" as it is now, and it was actually far easier in 1998 > than it is now to fit a "non-standard" VFS into Linux. Back in 1998 I > had > - plan 9 style union mounts > - private name spaces that worked for all programs > - 9p mounts > > and it was all pretty easy. The newer VFS layer has frozen more design > assumptions into practice, with the result that it is harder, not > easier, to put interesting file systems into Linux. It was a bit > harder for 2.2, even harder for 2.4 and, as you know, a pain in the > neck in 2.6. It's easier, I suppose, to put boring file systems in, > that act like all the other ones. There's a paper in that reality > somewhere ... > > > However, such support is mainly necessary for folks looking to remote > > access feature rich on-disk file-systems. I believe straight 9p is > > more than adequate for 99% of synthetic file systems with something as > > simple as 9p2000.u giving you extra bits necessary for basic UNIX > > compatibility. > > I think that you are absolutely right. My experience certainly > supports this statement ... > > It's an interesting idea to rethink v9fs with the current Linux VFS in > mind. I had not heard that one. It makes a lot of sense, however. > > At the Google meeting, one discussion about putting private name > spaces in-kernel (as opposed to the current 9p-fuse which several at > Google are using) was to just have a per-user name space, mounted at > some well known place, and work with that. This was also very similar > to what I did on the original: codify the mount point to be at > /private: all users had to do a private mount (which was not a > privileged operation, hence easy) at /private; no user could see > anothers private mount; and I never had to deal with the issue of > multi-user access to single file, which has caused some work (see the > code). On the old stuff, for each private namespace file, there was > only one user, and you figured out who it was by looking in the > "inode". Going to one user per mount might also make life simpler. > That would, however, go against another idea, which was to use 9p to > serve root partitions. I'm not a big believer in network-mounted root > file systems, so am less concerned with this :-) > > ron > >