From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin C.Atkins To: 9fans@cse.psu.edu Subject: Re: [9fans] A proposal regarding # in bind Message-Id: <20030225103008.5ec58473.martin@mca-ltd.com> In-Reply-To: <3203694a344338d2aae59b328b9fe67a@vitanuova.com> References: <3203694a344338d2aae59b328b9fe67a@vitanuova.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 25 Feb 2003 10:30:08 +0530 Topicbox-Message-UUID: 70ff297e-eacb-11e9-9e20-41e7f4b1d025 On Mon, 24 Feb 2003 19:04:01 0000 rog@vitanuova.com wrote: >... > > 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. I was hoping to avoid any visibility from user space of the mechanism for attaching /proto. (See my reply to Rob's message) > > 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)? Ahh yes - good point. That's one reason why I said that it may be going too far! > 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. > See above.... Martin -- Martin C. Atkins martin@mca-ltd.com Mission Critical Applications Ltd, U.K. http://www.mca-ltd.com