From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  9 May 2000 13:05:24 -0400
From: rob pike rob@plan9.bell-labs.com
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Topicbox-Message-UUID: a90f7768-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000509170524.ZqD3yQa1rrfhalbmO9wdHAa_qeH12GF6GhazON1FwoU@z>

	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.

Resources will get used up.   As with any abuse of system services, bind has
the potential to exhaust resources.  That alone is not sufficient reason to reject
a design; otherwise fork() and malloc() wouldn't exist.

	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,

Making the command do the work instead of the system call gets you
into the kind of problems that confuse people.  If bind only works
cleanly as a command, then programs that call on it through the
library will behave differently from seemingly equivalent shell
scripts.  Phooey.  Why in the shell can I cd somewhere but not chdir
there?  Because cd is a bucket of shell magic, but chdir is a system
call.  Such distinctions don't make a system perspicuous.

This discussion is about implementation.  Back up a level.  What are
your goals?  Plan 9's per-process name space builds on and interacts
with other system facilities to get its power.  Linux doesn't have
user-level file systems, for example; what's the advantage?  If all
you get is the ability to replace $PATH with a unioned /bin, it's not
worth the trouble.  If on the other hand you want to build interesting
name spaces that can be shared across the network, as in Plan 9, your
design leaves a lot to be desired.

-rob