From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <330f966d8a62b319b89a160f356b2ce9@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] remote 9p multiplexing From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 26 Apr 2004 20:44:32 +0100 Topicbox-Message-UUID: 6eed1734-eacd-11e9-9e20-41e7f4b1d025 > when afd != -1, the fd in mount(fd, afd, where, flags) is redundant. > if you mounted 9P services by opening them, running authentication, > and then calling mount(afd, where, flags), we could adopt the convention > that the 9P connection for the mount is the one where afd is a fid. yes. > then Tauth invents a fid out of thin air to bootstrap a connection, > but if the fid has been gotten by open, mounting this fid can be > handled without further encapsulation. actually, i was imagining that you would not be allowed to open an auth file, only Tauth it. the open doesn't really give you much and you've got to call auth to provide the uname and aname before you can read or write it anyway. this does change current 9p semantics (currently the auth fid must not currently exist; in this scheme it could optionally exist), but in a compatible way. > of course, they'd more properly be called something else, since this > has nothing to do with authentication and everything to do with > setting up the context of a new 9P conversation. maybe session fids. i'm not sure - i think auth fids is *exactly* what they are. by walking to it and calling fauth(2) on it, you're introducing yourself (authenticating) to whatever's at the other end. the 'A' that you might see in an ls -l listing could also stand for "attach"... but they'd be potentially useful even without doing the attach, as a way for a client to ascertain the identity of a party at the other end. > that's really neat. it separates the setup from the actual session > in a nice clean way without the clumsy 9P1 kernel hack and > without any encapsulation overhead. there's more to it than that. it makes possible some useful 9p server designs that were not previously possible. for instance, it becomes much more reasonable to implement a web browser in the namespace. the server could provide a namespace for a single web page, holding the data for the page, but also an auth file for each link in the page. mounting the auth file would provide the namespace for the page linked to. (https authentication falls out naturally). deciding which web pages to keep current (i.e. mounted) is a matter for the client, as it should be. it also makes sense for servers that wish to provide multiple instances of a service, but don't care about letting clients see all the instances that have been created, in the same way that the #| device does. to take a specific example, the Inferno grid scheduler program exports a single namespace to all its clients. one of those files, when opened, represents a single worker instance to the server. if i'm on a multi-process machine, i can open the file several times, and the server sees several workers. the difficulty comes when i wish to send an abort message to a particular worker - the same worker might have opened the "stoptask" file, but i have no way of associating the two opens, so i am forced to provide one such file for each attach, and let the client do the multiplexing. the current alternative would be to provide a "clone"-style interface, with one directory for each worker, each containing two files. not only does that make the server implementation more complex (have to be able to enumerate all clients, have to allocate appropriate qid space, etc) but it also makes the client interface more complex (open clone file, read id, etc, vs. open file). the auth file interface gives me the best of both worlds: i could provide an auth file for workers to attach to, giving each a namespace containing the two files (and any others necessary), and wouldn't have to worry about enumerability or qid space at all. oh yes, it also seems a natural representation for dynamically loaded device drivers. and it can solve world hunger too.