From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 19 Nov 2008 18:56:14 -0800 From: "Roman V. Shaposhnik" In-reply-to: <1575ef9ac681cb48018b7328ee52e953@quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <4924D1CE.9000001@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QVg1KKnby/xtCJyuJD5BaQ)" References: <1575ef9ac681cb48018b7328ee52e953@quanstro.net> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Subject: Re: [9fans] fd2path and devsrv Topicbox-Message-UUID: 4a4a93a0-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --Boundary_(ID_QVg1KKnby/xtCJyuJD5BaQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/19/08 17:41, erik quanstrom wrote: >> Ok, I can understand why devproc.c does it: it is easy to discover the >> name of the actual Chan if you know the node in /srv: >> fd = open("#s/stuff", OREAD); >> fd2chan(fd, buf, sizeof(buf)); >> close(fd); >> but not the other way around. Buit why ns(1) doesn't have the above >> code? >> > > i assume that you mean fd2path. Yes. Sorry -- clumsy fingers :-( > i think the answer to your question is that it's a lot more useful > to know that it's #s/boot rather than /net/il/0/data. Really? Why? With /net/il/0/data you have an option of digging deeper and finding out the other end's address, etc. Or to flip the question -- what information does #s/boot provide? > one cares more about what it does than the particulars of the > connection. the fact that #s/boot is the 0th il connection and > not the nth wouldn't matter much unless you were debugging > the ip stack. > > or is there some reason why this is interesting that i'm missing? > Well, to me knowing that mount came out of #s/stuff has never seemed to be all that useful -- I can't imagine a question that this will answer. So, unless I am missing something I'd say it would be much more reasonable for ns(1) to do that translation as much as it does translate /net/il/0/data into the address of the remote end. Once again -- this is a bit of an open-ended question: I just want to know the experience of others and whether they find seeing #s/stuff useful at all. Thanks, Roman. --Boundary_(ID_QVg1KKnby/xtCJyuJD5BaQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 11/19/08 17:41, erik quanstrom wrote: 
Ok, I can understand why devproc.c does it: it is easy to discover the
name of the actual Chan if you know the node in /srv:
   fd = open("#s/stuff", OREAD);
   fd2chan(fd, buf, sizeof(buf));
   close(fd);
but not the other way around. Buit why ns(1) doesn't have the above
code?
    

i assume that you mean fd2path.
Yes. Sorry -- clumsy fingers :-(

i think the answer to your question is that it's a lot more useful
to know that it's #s/boot rather than /net/il/0/data.
Really? Why? With /net/il/0/data you have an option of digging deeper and
finding out the other end's address, etc. Or to flip the question -- what
information does #s/boot provide?

one cares more about what it does than the particulars of the
connection.  the fact that #s/boot is the 0th il connection and
not the nth wouldn't matter much unless you were debugging
the ip stack.

or is there some reason why this is interesting that i'm missing?
Well, to me knowing that mount came out of #s/stuff has never seemed to
be all that useful -- I can't imagine a question that this will answer. So, unless
I am missing something I'd say it would be much more reasonable for ns(1)
to do that translation as much as it does translate /net/il/0/data into the
address of the remote end.

Once again -- this is a bit of an open-ended question: I just want to know
the experience of others and whether they find seeing #s/stuff useful
at all.

Thanks,
Roman.
--Boundary_(ID_QVg1KKnby/xtCJyuJD5BaQ)--