From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 2 Dec 2008 10:04:57 -0800 From: "Roman V. Shaposhnik" In-reply-to: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1228241097.7593.40.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1FAD6133-18F8-444F-BD6E-795999DE3170@sun.com> <1228155909.18951.33.camel@goose.sun.com> Subject: Re: [9fans] How to implement a moral equivalent of automounter in Plan9? Topicbox-Message-UUID: 5584312c-ead4-11e9-9d60-3106f5b1d025 Hi, Russ! Firs of all -- thank a lot for answering all of my question in a very detailed manner. I really do appreciate it! Now, if you don't mind, I still have just one question left: On Mon, 2008-12-01 at 16:55 -0800, Russ Cox wrote: > > That's very similar to what I referred to as a "synthetic filesystem > > doing the right stuff". But as I pointed out in my original email > > this approach has a downside of never exporting these mounts > > into the namespace of the process that caused them. > > You'd have the program export its own name space, > a delicate but not impossible dance. Then its mounts > would be exported too. That's pretty much what I'm after. Now, the question I still have is this: was there a clear reason behind deciding not letting the kernel help with something like that? I would imagine that making '#p'//ns writable and receptive to messages of exact same format that is being output right now (plus an 'unmount X Y' message) would be a very natural thought in a Plan9 environment. Yet, it wasn't implemented that way which makes me believe that I do (as usual) overlook something obvious here. Please give me a hint to what it might be that renders the idea as a bad one. Thanks, Roman. P.S. Thinking for a couple more minutes makes me believe that a writable '#p'//ns might even be used to implement mount/bind syscall. Which, on the surface, would make it even more appealing.