The point is that you need a way for the chan to know how to reach the file server. At some point, IIRC, in 2nd ed. Plan B, the plan b kernel tried to maintain the name (address) of the server for each chan and the relative path for the file in the server. Also, for some servers (eg. tarfs), you need the server to help by providing the information regarding where is it (in many cases at the end of the pipe).
To make a long story short, following conventions so that the name space was not too twisted made things easier for us. By looking to waht fd2path says we could always go to /n/blah/... or recognize that the path came from a particular device. BTW, I´d love to hear other experiences regarding ns or path reconstruction. On Wed, Nov 19, 2008 at 6:45 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote: > Hi Guys, > > I was rereading selected places of Rob's "Getting Dot-Dot Right" > paper and it suddenly occurred to me that the example he provides > there is something that I have always wanted to have. Here it is: > % cat /proc/125099/ns > ..... > mount -c /net/il/134/data /mnt/term > .... > cd /usr/rob > > And, of course, if you run ns(1) it gets even better: > % ns > ... > mount -c il!135.104.3.100!12884 /mnt/term > ... > > Now, when I happen to be logged into the Plan9 the best I can > see is this: > % cat /proc/2012/ns > .... > mount '#s/sources' /n/sources > .... > Which is fair (the mount really did have /srv/sources as an argument) > but makes me ask the next question: how can Rob's experience be > achieved here? How can I get to the Channel (with the hope of invoking > fd2path) that was given to devsrv when /srv/sources was created? > > Thanks, > Roman. > > >
