Re: [9fans] How to implement a moral equivalent of automounter in Plan9?

["Rob Pike" <robpike@gmail.com>]

On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <rsc@swtch.com> 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