[9fans] fd2path and devsrv

[9fans] fd2path and devsrv

[Roman V. Shaposhnik]

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.

Re: [9fans] fd2path and devsrv

[Francisco J Ballesteros]

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 <rvs@sun.com> 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.
>
>
>

Re: [9fans] fd2path and devsrv

[Roman V. Shaposhnik]

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 = 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 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.

Me too.

Thanks,
Roman.

Re: [9fans] fd2path and devsrv

[erik quanstrom]

> 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.  as in

minooka; cat fd2path.c
#include <u.h>
#include <libc.h>

void
main(void)
{
	char buf[1024];
	int fd;

	fd = open ("#s/boot", OREAD);
	if(fd != -1 && fd2path(fd, buf, sizeof buf) != -1)
		fprint(2, "%s\n", buf);
	close(fd);
	exits("");
}
minooka; fd2path
/net/il/0/data

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.  generally
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?

- erik

Re: [9fans] fd2path and devsrv

[Roman V. Shaposhnik]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2266 bytes --]

Re: [9fans] fd2path and devsrv

[erik quanstrom]

>> 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?

the reason why #s/boot is useful is twofold.  the name means something.
this is a connection to the fs used to boot the machine.  second, /net/il/0/data
can't be mounted.  if you want the name of something to mount, ns gives
you want you want.

you're not precluded from digging around and finding what #s/boot
points to.  why are you complaining that ns gives you the most useful
information?

> 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.

!?  you can mount it!  the network connection by itself is not useful.

- erik

Re: [9fans] fd2path and devsrv

[Roman Shaposhnik]

On Nov 19, 2008, at 6:55 PM, erik quanstrom wrote:
>>> 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?
>
> the reason why #s/boot is useful is twofold.  the name means
> something.

#s/boot is a bit special but I get your general point. So, let me
rephrase:
the usefulness of #s/foo is determined by the naming convention.

> this is a connection to the fs used to boot the machine.  second, /
> net/il/0/data
> can't be mounted.

Sure it can:
     % srv tcp!sources.cs.bell-labs.com!9fs test
     % ls /net/tcp
     /net/tcp/0
     /net/tcp/1
     /net/tcp/2
     /net/tcp/clone
     % mount -n /net/tcp/2/data /n/test
     %

>  if you want the name of something to mount, ns gives
> you want you want.

Not really, what gets mounted is a Chan to /net/tcp/*/data
as far as I cat tell.

>  why are you complaining that ns gives you the most useful
> information?

I'm not complaining about /proc/*/ns I'm complaining about ns(1)
which already does some translations of raw data from /proc/*/ns
but not this particular one.

Thanks,
Roman.

Re: [9fans] fd2path and devsrv

[erik quanstrom]

> Sure it can:
>      % srv tcp!sources.cs.bell-labs.com!9fs test
>      % ls /net/tcp
>      /net/tcp/0
>      /net/tcp/1
>      /net/tcp/2
>      /net/tcp/clone
>      % mount -n /net/tcp/2/data /n/test
>      %

; mount /net/il/0/data /n/x
mount: mount /n/x: version conversion

Re: [9fans] fd2path and devsrv

[Roman Shaposhnik]

On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
>> Sure it can:
>>     % srv tcp!sources.cs.bell-labs.com!9fs test
>>     % ls /net/tcp
>>     /net/tcp/0
>>     /net/tcp/1
>>     /net/tcp/2
>>     /net/tcp/clone
>>     % mount -n /net/tcp/2/data /n/test
>>     %
>
> ; mount /net/il/0/data /n/x
> mount: mount /n/x: version conversion

Huh? What gives -- of course I ran my example
in 9vx, but it shouldn't matter -- should it?

Thanks,
Roman.

Re: [9fans] fd2path and devsrv

[erik quanstrom]

> On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
> >> Sure it can:
> >>     % srv tcp!sources.cs.bell-labs.com!9fs test
> >>     % ls /net/tcp
> >>     /net/tcp/0
> >>     /net/tcp/1
> >>     /net/tcp/2
> >>     /net/tcp/clone
> >>     % mount -n /net/tcp/2/data /n/test
> >>     %
> >
> > ; mount /net/il/0/data /n/x
> > mount: mount /n/x: version conversion
>
> Huh? What gives -- of course I ran my example
> in 9vx, but it shouldn't matter -- should it?

your example does work; mine was a counter example.

but in pointing out the nits, i missed the point.
according to the ns(1) man page

          [...]The out-
          put is in the form of an rc(1) script that could, in princi-
          ple, recreate the name space.  The output is produced by
          reading and reformatting the contents of /proc/pid/ns.

so following fd2path along its merry way down
to the source doesn't help generating such a script.
i could think of cases where it would be a hinderance.

perhaps you want a new program, nsroot that does
what you suggest.

- erik

Re: [9fans] fd2path and devsrv

[Roman Shaposhnik]

On Nov 19, 2008, at 8:14 PM, erik quanstrom wrote:
>> On Nov 19, 2008, at 7:32 PM, erik quanstrom wrote:
>>>> Sure it can:
>>>>    % srv tcp!sources.cs.bell-labs.com!9fs test
>>>>    % ls /net/tcp
>>>>    /net/tcp/0
>>>>    /net/tcp/1
>>>>    /net/tcp/2
>>>>    /net/tcp/clone
>>>>    % mount -n /net/tcp/2/data /n/test
>>>>    %
>>>
>>> ; mount /net/il/0/data /n/x
>>> mount: mount /n/x: version conversion
>>
>> Huh? What gives -- of course I ran my example
>> in 9vx, but it shouldn't matter -- should it?
>
> your example does work; mine was a counter example.

But now I'm curious -- why didn't it work?

> so following fd2path along its merry way down
> to the source doesn't help generating such a script.
> i could think of cases where it would be a hinderance.

Fair enough. It does, invalidate the example given by
Rob in his article though:

-------------------------------------------------------------------------------
Another program, ns, does this; it reads the /proc/n/ns file, decodes  
the information,
and interprets it, translating the network addresses and quoting the  
names when required:
...
mount -a ’#s/dns’ /net
...
mount -c il!135.104.3.100!12884 /mnt/term
-------------------------------------------------------------------------------

Thanks,
Roman.

Re: [9fans] fd2path and devsrv

[roger peppe]

On Wed, Nov 19, 2008 at 7:36 PM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> BTW, I´d love to hear other experiences regarding ns or path reconstruction.

i wrote a reverse path evaluator (ftrans) for inferno - given a path,
it uses fd2path and /prog/xx/ns to attempt to return the
originally mounted path.

the reason for implementing it was to make it easier to generate
paths to be used externally, in particular for the os(1) command.
it gives a certain amount of freedom to re-bind paths locally
to make convenient aliases without needing to modify all the
software to take account of the new convention.

obviously there are many cases where it's not possible
(e.g. where two directories from the same filesystem
are union-bound together), but it does work ok.

in cases where the bind is ambiguous, it stats ancestors of the file
and disambiguates by looking at the device letter (it'd be
useful if ns provided the dev number of the mounted file,
as well as the device letter).

it punts on actual mounts - there's nothing useful you can do
programmatically with a mount ns entry, you can't re-mount it, and
ns doesn't record how the original Chan was generated (that's
not true in plan 9, where you can remount the #s entry, of course).

instead, it takes an association list of "stop paths" - paths where it
stops the search and returns the associated answer.

this means that where a particular path is ambiguous, or unresolvable
(e.g. mount kremvax /n/krem), we can associate that path with
the desired outcome, if there is one.

Re: [9fans] fd2path and devsrv

[Steve Simon]

The dos(1) command I wrote (in the style of cpu(1) but attaches to Windows boxen)
uses a configuration file describing how the windows directories are
mounted (using cifs(1)) on plan9. It also reads /proc/$pid/namespace to
learn of any additional mounts so it can reliable translate plan9 paths
to windows ones and back again.

for example, I mount my home directory on the Windows server at $home/work in plan9
and then add various useful parts of the windows filesystem under that.

When I cd into one of these directories and run dos(1) it can then work out where
it should chdir(2) to on the windows box before starting cmd.exe.

Aditionally dos(1) keeps track of the current directory on windows and updates
/dev/wdir so the plumber and rio (for file name completeion) work as expected
even on the output of the windows DIR command.

Overall its a bit string and sticky-tape but it works and and you cannot
see the joins.

-Steve

Re: [9fans] fd2path and devsrv

[roger peppe]

On Thu, Nov 20, 2008 at 12:59 PM, Steve Simon <steve@quintile.net> wrote:
> The dos(1) command I wrote (in the style of cpu(1) but attaches to Windows boxen)
> uses a configuration file describing how the windows directories are
> mounted (using cifs(1)) on plan9. It also reads /proc/$pid/namespace to
> learn of any additional mounts so it can reliable translate plan9 paths
> to windows ones and back again.

interesting. that's almost exactly what i was doing with ftrans
(using inferno's cmd(3) device). i wasn't thinking about long lived
sessions, though, so i didn't fiddle with /dev/wdir.

i wonder how similar the code ended up being...

  rog.