Re: VSTa mounting and paths

> Mumble. I'm thinking about folding namer paths into the main open() code
> path. Currently they're distinct, and it's causing most of your confusion.
>
> The namer path should disk/wd. This maps a path to a port number. When you
> mount that port number in your namespace, the server at that port number
> looks like a directory tree. So disk/wd:wd0_dos0 is shorthand,
> conceptually, for "mount disk/wd on /FOO, and then open /FOO/wd0_dos0". I
> say conceptually, because it doesn't really join your filesystem namespace.

[Andrew's mounting explanation deleted]

That also cleared up some confusion I had about the whole disk/wd:??
bussiness. Into the FAQ it goes :)

However, it reinforces the previous thoughts I had. I assume (perhaps
incorrectly) that when you said you were thinking of folding namer paths
into the main open() code path that "disk/wd" would essentally be part of
the man open() code path, thus you could directly mount "disk/wd/wd0_dos0"
somewhere? While I think the shorthand and concept behind the
disk/wd:wd0_disk0 is slightly confusing (espectially before a proper
explanation), I think it would make more sense to keep the namer paths
separate, but allow them to work slightly more like normal paths,
in that "disk/wd/wd0_dos0 would mean to open "wd0_dos0" from the
server available in the namer path "disk/wd". Perhaps these things are nearly
mutually exclusive, or perhaps I'm still confused about how namer paths
are distinct from the main pathspace.

After having said that, I would like to test if I understand the idea
behind the current layout. If I were to create a second "namer" which would
make itself available in the "real" first namer, and then run wd and
have itself registered in the second namer, would it then be logical to
use "namer2:disk/wd:wd0_dos0" to refer to the partition?

If this concept is correct, then I understand the logic behind things
and I really think that just a good expanation is the real solution to the
confusion.

-- 
jeske_at_uiuc.edu   + David Jeske(N9LCA)<A HREF="http://www.cen.uiuc.edu/~jeske/">
NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008
    User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) </A>
-- 
jeske_at_uiuc.edu   + David Jeske(N9LCA)<A HREF="http://www.cen.uiuc.edu/~jeske/">
NeXTMail accepted + CompEng Student/NeXT Programmer/Call Gtalk at (708)998-0008
    User of Linux/NEXT/DOS/WIN/OS.2/VSTa (all coexisting on one system) </A>
FromFrom vandys@puli.cisco.com  Mon Jun 19 18:31:05 1995
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00139; Mon, 19 Jun 1995 18:31:04 -0700
Received: from w4sun5.ccl.itri.org.tw (w4sun5.ccl.itri.org.tw [140.96.111.5]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id CAA07517 for <vsta@cisco.com>; Mon, 19 Jun 199 vandys@puli.cisco.com  Mon Jun 19 18:31:12 1995
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by amri.cisco.com (8.3/8.3) with ESMTP id SAA00141; Mon, 19 Jun 1995 18:31:06 -0700
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id BAA06138 for <vsta@cisco.com>; Mon, 19 Jun 1995 01:37:05 -0700
Received: from punt.demon.co.uk by disperse.demon.co.uk id ab12377;
          19 Jun 95 9:28 +0100
Received: from humbug.demon.co.uk by punt.de5 02:36:30 -0700
Received: from cclw400.ccl.itri.org.tw by w4sun5.ccl.itri.org.tw (4.1/SMI-4.1)
	id AA19379; Mon, 19 Jun 95 17:50:29 CST
Received: from CCLW400/SpoolDir by cclw400.ccl.itri.org.tw (Mercury 1.13);
    Mon, 19 Jun 95 17:30:48 gmt+800
Received: from SpoolDir by CCLW400 (Mercury 1.13); Mon, 19 Jun 95 17:30:40 gmt+800
From: "James Lee" <JLEE@CCLW400.CCL.ITRI.ORG.TW>
Organization:  ITRI/CCL/W400
To: vsta@cisco.com
Date:          Mon, 19 Jun 1995 17:30:37 GMT+800
Subject:       vsta info
Priority: normal
X-Mailer: Pegasus Maimon.co.uk id aa15692;
          19 Jun 95 9:28 +0100
Received: by humbug.demon.co.uk (Linux Smail3.1.29.1 #3)
	id m0sNbun-00036rC; Mon, 19 Jun 95 09:10 BST
Message-Id: <m0sNbun-00036rC@humbug.demon.co.uk>
From: Dave Hudson <dave@humbug.demon.co.uk>
Subject: Re: VSTa mounting and paths
To: jeske@uiuc.edu
Date: Mon, 19 Jun 1995 09:10:36 +0100 (BST)
Cc: VSTa mailing list <vsta@cisco.com>
In-Reply-To: <199506161956.OAA16620@fiction.isdn.uiuc.edu> from "David Jeske" at Jun 16, 95 02:56:43 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Versiol/Windows (v1.22)
Message-Id: <3A4BFC70BD0@cclw400.ccl.itri.org.tw>
Please email me more info about vsta. Thanks.
James Lee
Computer & Communications Lab
Industrial Technology Research Institute
phone: 886-35-78-1390x303
fax: 886-35-78-1398
jlee@ccl.itri.org.tw
n: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2536      
Hi,
David Jeske wrote:
> 
> > Mumble.  I'm thinking about folding namer paths into the main open() code
> > path.  Currently they're distinct, and it's causing most of your confusion.
> > 
> > The namer path should disk/wd.  This maps a path to a port number.  When you
> > mount that port number in your namespace, the server at that port number
> > looks like a directory tree.  So disk/wd:wd0_dos0 is shorthand,
> > conceptually, for "mount disk/wd on /FOO, and then open /FOO/wd0_dos0".  I
> > say conceptually, because it doesn't really join your filesystem namespace.
> 
> However, it reinforces the previous thoughts I had. I assume (perhaps
> incorrectly) that when you said you were thinking of folding namer paths
> into the main open() code path that "disk/wd" would essentally be part of
> the man open() code path, thus you could directly mount "disk/wd/wd0_dos0"
> somewhere? While I think the shorthand and concept behind the 
> disk/wd:wd0_disk0 is slightly confusing (espectially before a proper 
> explanation), I think it would make more sense to keep the namer paths 
> separate, but allow them to work slightly more like normal paths,
> in that "disk/wd/wd0_dos0 would mean to open "wd0_dos0" from the
> server available in the namer path "disk/wd". Perhaps these things are nearly
> mutually exclusive, or perhaps I'm still confused about how namer paths
> are distinct from the main pathspace. 
I think the confusion comes because it's difficult to differentiate a server
path from a normal path.  The obvious solution that springs to mind is to
prefix server paths with a magic character.  We already have "@" (if I
remember correctly) for handling environment path expansions.  Plan 9
devices use a prefix hash symbol "#" (I believe this is known as a pound
symbol in the US (or at least that's what the Plan 9 docs call it), but that
confuses me as a pound symbol is the currency one (looks like a squiggly L)
over here :-)).  Perhaps the solution is to patch libc to allow something
similar, thus we have:
	#disk/wd:wd0_dos0
as a server/path, and the more conventional
	/dev/wd/wd0_dos0
for when #disk/wd has been mounted at /dev.
This might mean a reasonable amount of extra work to patch some of the
utils (actually removing quite a bit of code I suspect), but would give us a
pretty consistent view.  If nothing else, adopting something like this gives
us a consistent way to name files within VSTa (it's implicit whether we have
a server reference or a "mounted" pathname).
				Regards,
				Dave