From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 19 Nov 2008 17:37:20 -0800
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <8ccc8ba40811191136g54cde269g98ffafdcac3f1451@mail.gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <1227145040.19266.383.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
References: <1227116745.19266.342.camel@goose.sun.com>
	<8ccc8ba40811191136g54cde269g98ffafdcac3f1451@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] fd2path and devsrv
Topicbox-Message-UUID: 4a3a6926-ead4-11e9-9d60-3106f5b1d025

On Wed, 2008-11-19 at 20:36 +0100, Francisco J Ballesteros wrote:
> The point is that you need a way for the chan to know how to reach the
> file server.

That is a larger point here, indeed. However, my question was a simpler
one: is there any reason to show '#s/sutff' at all? Could I ever be
interested in the "proxy" as opposed to the name of the actual Chan?

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 =3D 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?

> To make a long story short, following conventions so that the name spac=
e
> was not too twisted made things easier for us. By looking to waht fd2pa=
th
> says we could always go to /n/blah/... or recognize that the path
> came from a particular device.
>=20
> BTW, I=C2=B4d love to hear other experiences regarding ns or path recon=
struction.

Me too.

Thanks,
Roman.