From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  9 May 2000 12:31:41 -0400
From: Alexander Viro viro@math.psu.edu
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Topicbox-Message-UUID: a8fafe46-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000509163141.4cd8UVG-iagE5XcP5DsHLPMUiYiw0U0FOETJ1g0PTGc@z>



On Tue, 9 May 2000, rob pike wrote:

> 	One difference being that our equivalent of bind() binds only the chunk
> 	that contains the object we are binding.
>
> I think this is a big conceptual mistake.  It means that the effect of the bind
> depends on the invisible underlying structure of the name space rather than
> its visible appearance.  Since the point of a name space is to give intuitive
> names to arbitrary structure, your design is sure to confuse.   Worse, I
> think it negates the reasons for the exercise.

Hmm... OK, so how do you deal with the situation when / is bound onto /mnt
and luser does chdir("mnt"); n times? You either have to open a DoS
(kernel memory exhaustion) _or_ forget what n was.

> As an example, our /bin and /dev directories are complex union directories.
> The ability to rebind /bin or /dev en masse is a boon for programs that wish
> to construct private name spaces, for security or other purposes. In your
> world, programs that wish to do this must reconstruct the union directories,
> a serious obstacle for things like shell scripts.

Having bind(1) able to reproduce that structure is trivial. So I don't
think that it's going to be a problem for scripts - none of your examples
actually would create a loop, so bind(1) would be quite happy. However,

> I understand your desire to avoid loops, but a) it's easy to make the tools
> that walk trees robust against loops and b) it's not nearly as big a deal as
> you think (well, your phrase is "rather bad", hardly a rallying cry in support
> of your design).  You're second-guessing yourself into a confusing situation,
> appealing to the implementation to argue for the behavior you provide
> instead of offering transparent, clean behavior.

... I would like to know how do you deal with the situation described
above. The problem is not implementation-dependent. Again, I can provide
bind(1) that does the same thing as your bind(1) unless you are trying to
create a loop. And shell scripts don't do plain syscalls...