Re: [9fans] A proposal regarding # in bind

[rog@vitanuova.com]

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.