From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: Russ Cox To: 9fans@cse.psu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <323e1127492657ee8f9f34692a52c7fa@vitanuova.com> Subject: [9fans] remote 9p multiplexing Date: Mon, 26 Apr 2004 14:54:49 -0400 Topicbox-Message-UUID: 6ee43a7e-eacd-11e9-9e20-41e7f4b1d025 > say we've imported a namespace from a remote machine. in the > namespace is a /srv directory, containing various exported 9p > services. we wish to mount one of them. okay, let's return to this. in my scheme, since the remote kernel is doing appropriate multiplexing, we don't need to do anything special to use the remote /srv/foo. (actually, we the local machine don't need to do anything special even now, but that's because exportfs the program is invoking itself recursively behind our back.) of course, since /srv/foo is treated like a normal file, there is message encapsulation and the like, which does incur extra latency. i never claimed to handle this case. i didn't realize you were claiming to handle it. it seems what's needed to handle it is some way to introduce a new conversation into an extant 9P connection. david mazieres suggested such a thing a few years ago when he interned at bell labs. in his scheme there was (approximately) a Ttunnel/Rtunnel message that took the place of Topen/Ropen for 9P connections, and the net effect was that the 9P connection just opened could use the original 9P connection for its messages rather than encapsulate them in Tread/Rread/Twrite/Rwrite responses. i never understood the details (i'm not sure anyone did). i think the crux of your message is that Tauth/Rauth can be coerced to let us pull this off, because it introduces a separate "attach space". i'm going to try to paraphrase: 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. 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. now *that* is cool. the auth fids are really an indirection layer and Tauth/Rauth just provides a base. 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. 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. sorry about being so dense i didn't get it the first time around. russ