On Thu, Nov 20, 2008 at 12:59 PM, Steve Simon <[EMAIL PROTECTED]> 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/namespa
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
On Wed, Nov 19, 2008 at 7:36 PM, Francisco J Ballesteros <[EMAIL PROTECTED]>
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
origina
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
> 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
> >> %
> >
> > ; mou
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 c
> 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
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 f
>> 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
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
> 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 as
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
inte
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 ne
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
14 matches
Mail list logo
