On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <[EMAIL PROTECTED]> 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
