/sys/doc/ Documentation archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bind() and mount() confusion

> But it does give rise to a question that perhaps the Inferno developers
> could answer:  Why two namespaces?  Things would seem to work just as
> well if the kernel magically mounted all the kernel threads in their
> default location.  And for those resources that justify having distinct
> copies, have a name that clones a new subtree.

The # notation was invented long ago (a scarily long time ago - in the
earliest days of Plan 9) as a hack to give names to kernel devices.  It
always bothered me that local trees were attached using bind but
remote ones with mount. But it works out fine in practice, so it stayed
that way.

Are the #'ed trees a separate name space?  Well, yes, but it's not useful
to think of them that way.  It is useful, however, to consider the process
to have one true namespace with the ability to attach resources, so that's
how we think about it.  It's an accident of history that some resources
come by bind, others by mount, but an advantageous accident.

If the kernel magically mounted the devices, it would go against the grain
of the system.  Take off your Unix hat for a minute.   The Plan 9 or Inferno
hat makes you think like this:

	A process starts with nothing, and attaches only those resources
	it needs into a private space.

Doing what you suggest muddies that design, and along the way makes
it more awkward to control access to resources (e.g. pctl(NODEVS) to disable
binds to local devices), to acquire guaranteed access to local ones (look at
#c rather than /dev to be sure we're not being substituted), to sniff a device
to see if it's local (stat it to see what type of file it is), and so on.