From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3203694a344338d2aae59b328b9fe67a@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] A proposal regarding # in bind
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 24 Feb 2003 19:04:01 +0000
Topicbox-Message-UUID: 70a3b2f6-eacb-11e9-9e20-41e7f4b1d025

rob:
> Your proposal is interesting but doesn't solve the bootstrap problem.
> How would /proto get mounted?  You see, the thing about # names
> is that they're really not in the name space, and that comes in handy
> when booting or creating a name space from scratch, such as in
> listen.  Since a program can't name the proto driver, how does one
> establish a connection to it?  I'm sure there's a way; I just wonder
> what your plan is.

two possibilities spring to mind:

a) there's still an escape from the namespace, but a smaller one:
there could be one (and only one) device nameable in the '#' name
space, the proto device.  (whether one allows an attach spec is a
matter of taste).  that at least would solve some of the naming
problems.

b) have a special system call for attaching proto.

martin:
> One could have a /proto/ctl file to which commands could be sent to remove
> (or even add?!) devices from the visibility of this, and inheriting, processes
> (a sort of fine-grained NODEVS).

this would require that the namespace served by the proto device
was specific to a namespace group. how would the proto device
know to serve the same namespace to a process that's just
done an rfork(RFNAMEG)?

you could make it so each attach to '#' (the proto device) gave
you a new instance of that device, so:

	unmount /proto
	bind '#' /proto

would allow changing of availability of devices in /proto
without affecting anything else.