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: <20030225102715.4dc62b6c.martin@mca-ltd.com> In-Reply-To: <7bf536fa6ce3ddbe60a1a94c026d6f7e@mightycheese.com> References: <20030224204958.157fccfe.martin@mca-ltd.com> <7bf536fa6ce3ddbe60a1a94c026d6f7e@mightycheese.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Tue, 25 Feb 2003 10:27:15 +0530 Topicbox-Message-UUID: 710887c6-eacb-11e9-9e20-41e7f4b1d025 On Mon, 24 Feb 2003 10:36:42 -0800 "rob pike, esq." wrote: > # file names were just a hack to get started - literally to get started. > They were a place holder until a better idea came along. None has. Ah good - I'm not missing something obvious! > > # was never considered a great idea; I just needed some way to > name an unnamed resource. I deliberately chose # as the character > because it's the comment character in the shell and therefore is > really irritating to use. :-) I had wondered about how important it was to you that the '#' namespace was 'outside' the normal one, but given that things like: echo filsys fs kfs.file >'#Kcons/kfsctl' work, it doesn't seem to me to be such a separate namespace as might be. > 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. I thought I *had* addressed the bootstrap problem, but obviously it was not clear. I was remembering the new code for startboot that Russ posted on 24th Jan: > void > startboot(char *argv0, char **argv) > { > open(cons, OREAD); > open(cons, OWRITE); > open(cons, OWRITE); > bind(c, dev, MAFTER); > bind(ec, env, MAFTER); > bind(e, env, MCREATE|MAFTER); > bind(s, srv, MREPL|MCREATE); > exec(boot, argv); > for(;;); > } and thinking that the proto driver could be bound by some *internal* magic during the construction of the process before startboot gets started. Thus it should be inherited by every process that hasn't had a parent do "unmount /proto". NB. I don't know any of the details about how this first process gets started (I haven't looked!), and so have no idea how easy/horrible this might be. I am also assuming that all processes are ultimately children of this first process, a la Unix. I hope this is clear now. I did think that having this 'hack' in one place, and not using a system call or other special mechanism from user space would be good for being absolutely certain of the security of "unmount /proto". > > One thing I like about your proposal is that it would make it easier > to import devices from remote machines. One thing I don't like > about your proposal is that it would make it easier to import > devices from remote machines. Yes, I thought about this... both the pros and the cons! > > This all seems so obvious, that I can't understand why it hasn't always > > been done this way! > Many years of thinking, especially when given the ideas made possible > by the incomplete early implementations, can make hard things obvious. and obvious things hard? Yes - I've been there! :-) > -rob > Martin -- Martin C. Atkins martin@mca-ltd.com Mission Critical Applications Ltd, U.K. http://www.mca-ltd.com