From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <7359f0490812022123s7702736ep83ea45fa8059bbb8@mail.gmail.com> Date: Tue, 2 Dec 2008 21:23:00 -0800 From: "Rob Pike" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1228252641.16585.44.camel@goose.sun.com> Subject: Re: [9fans] How to implement a moral equivalent of automounter in Plan9? Topicbox-Message-UUID: 56f01864-ead4-11e9-9d60-3106f5b1d025 On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox wrote: >> a couple of questions come to mind. how does writing >> to a ns interact with shared namespaces? does it automaticly >> fork the namespace? seems iffy. which leads to the next >> obvious question >> >> how do you prevent a race between changing the namespace and >> opening fds? >> >> and, what about open file descriptors? >> >> seems like a big can of worms. > > None of these questions are any different in this > context than if there was simply some other process > sharing the name space and doing the same manipulations. > > A writable #p/pid/ns seems strange to me > (not nearly as natural as Roman suggested), > but maybe it would be fine. No one has cared > enough to explore it. > > I don't think a writable #p/pid/ns would really > help you write an automounter. You don't know > the pid you are getting the 9P request from > (maybe it is on another machine!). > > If I had to write an automounter like you describe > and I was going to tweak the kernel to make it > easier, I would change name spaces to be hierarchical, > so that rfork(RFNAMEG) (or perhaps some new bit) > insulates the parent from the child's modifications > but not vice versa. Then the automounter can sit > in some early name space and mount things, and all > the name spaces that were forked off would see them. > That is easier to reason about than writing #p/pid/ns. > > Russ Long ago I considered making the namespace not hierarchical but a set of spaces. The first level of complexity upwards would be to have two spaces: one that is per-process and one that is global or per-machine. It could of course be extended to more generality, hierarchy, etc. The reason I didn't was that the existing one-space system was almost good enough and any generalization seemed either too complex or too specific. There seemed no guiding principle to organize the design. So I left it alone even though in so doing I was leaving a problem on the table. -rob