Re: [9fans] A proposal regarding # in bind

Re: [9fans] A proposal regarding # in bind

[a]

// perhaps intro(3) should mention or include /sys/src/9/port/master.

then again, perhaps port/master should be up to date?
ア

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

> then again, perhaps port/master should be up to date?

it is.

Re: [9fans] A proposal regarding # in bind

[a]

i stand (gladly) corrected. thanks. i'm a bit behind on my
updates. i was about to say "well then maybe we should come
up with an automated way to ensure it stays that way" but
actually thought to check this time. sure enough, looks
like rsc's though of that, too. more thanks.
ア

Re: [9fans] A proposal regarding # in bind

[John Stalker]

In some sense # has to be a special case.  The / hierarchy is (potentially)
different for each process.  The # hierarchy is not.  You need a global
namespace from which to choose what to include in a local namespace.  At least
you do if you want children to be able to bind things which were not in their
parents' name spaces.  /ur or variants thereof in some sense hide a copy of
the global namespace inside the local one.  Whether that's a good thing or a
bad thing is partially a matter of aesthetics.  Since I actually like ed(1)
my opinion in questions of aesthetics should be regarded as worthless.
--
John Stalker
Department of Mathematics
Princeton University
(609)258-6469

Re: [9fans] A proposal regarding # in bind

[Fco.J.Ballesteros]

> In some sense # has to be a special case.  The / hierarchy is (potentially)
> different for each process.  The # hierarchy is not.  You need a global
> namespace from which to choose what to include in a local namespace.  At least

This suggests that we could just keep a separate (per machine)
namespace with all devices attached on it.  You could mount it,
then bind whatever you want from there to
"/ur", then unmount /n/devs if you dont want that to be there.

This would require also a change in devices like #| that build
resources on attach.

But after all the discussion, I just think that keeping '#' is the
simplest answer.

Re: [9fans] A proposal regarding # in bind

[rog]

> Suppose you recentered the kernel around 9P,
> building a muxer that wasn't process-based
> like devmnt's currently is.

one would also have to make devices more rigorous about use of
"writing process" resources, as presumably the device driver would no
longer have access to the user area of the process producing the
request, as would it not be necessary to send all 9p requests to a
driver down a Chan associated with that driver (and presumably every
driver would have at least one process reading 9p requests)?

so you'd be unable to post a file descriptor to /srv by writing its
integer file descriptor.

similarly you'd have to think of another way to give fs(3) access to
files to multiplex, or to give bind in ip(3) a device to bind an
interface to.

perhaps a system call to post a file descriptor to part of the
namespace?  but that comes with its own problems.

you'd lose a certain amount in context switch time too, which wouldn't
matter so much for some devices but might be a significant overhead in
others.

all those rough edges...

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

like i said, there's plenty to be thought through.
right now devmnt is the special case.  there may be
merit to turning things around so that devmnt is not
a special case (it's not clear devmnt would exist at
all as a driver) and devsrv and devfs are.  maybe
those special cases wouldn't be exportable, which
seems reasonable.  it certainly seems like a bug that
you can do:

	srvfs foo /
	mount /srv/foo /n/kremvax
	echo 0 >/n/kremvax/srv/foo0
	echo hello world >>/n/kremvax/srv/foo0

to completely screw up exportfs's file service.

another student and i at mit may walk further down
this path in a few months.  i also think that a good
9p mux is the right way to build drawterm, so it looks
like we're going to try that first.

Re: [9fans] A proposal regarding # in bind

[okamoto]

>> So ...
>>
>>     #*cons  == #c
>>     #*ether!0 == #l0
>>     #*ip!1 == #I1
>>     #*srv!auth == #sauth
>>
>
> I like '#*' idea.

I'm wondering why giving a more readable kernel device name is so important.
Those will be used only by whom making decision what kind of devices to give
to some end users.   In the Plan 9 environment, there might be only limitted number
of such administrator, and all the others can be 'end users'.   Those well educated
administrator can refer a table showing one rune charachter device name
and long one.

Just a kidding. ☺

Kenji

Re: [9fans] A proposal regarding # in bind

[Digby Tarvin]

More readable kernel device names sounds all very nice, but what I think
would be more beneficial is adopting a solution which reduces the number
of arbitrary name spaces.

It seems to me that the Plan9 name space can be viewed as one process
local tree rooted at '/', plus a forest of global trees rooted at
'#<glyph>'.

Is there any reason why that could not be cut down (no pun intended)
to one local and one global tree. So, for instance, '#c' becomes '#/c'
and 'ls #/' provides a listing of available devices?

Or perhaps the naming conventiones that should be adopted for
the 'global' namespace could be '//c', or even '#c' for syntactic
consistency (where the interpretation changes from a root called
'#c' to a directory 'c' in the root '#')

Of course more readable names could still be used if desired.
Or we could even add a new device file called something like
'description' which when read describes the device.

The educated administrator's table could then be produced on
demand by the simple command:
	cat '#*/description'
(using syntax proposal 3)

Regards,
DigbyT

>I'm wondering why giving a more readable kernel device name is so important.
>Those will be used only by whom making decision what kind of devices to give
>to some end users.   In the Plan 9 environment, there might be only limitted
>number of such administrator, and all the others can be 'end users'.
>Those well educated administrator can refer a table showing one rune
>charachter device name and long one.
>
>Just a kidding. b^X:
>
>Kenji
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

> Of course more readable names could still be used if desired.
> Or we could even add a new device file called something like
> 'description' which when read describes the device.

man pages.

having full names would make the man pages
easier to use.  perhaps intro(3) should mention
or include /sys/src/9/port/master.

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

Here's a different proposal, also just an idea rather
than a complete proposal, but perhaps worth pursuing.

Suppose you recentered the kernel around 9P,
building a muxer that wasn't process-based
like devmnt's currently is.  Then you could have
two system calls

	int exportfs(void);
	int exportdev(void);

that return file descriptors.  The file descriptor
returned by exportfs gives you a private 9P
conversation operating on your current name space.
You could post it or do anything else with it, just
like the similar call in inferno.

Exportdev() would return a 9P file descriptor
but for the devices.  You mount it to get the device
tree.  (Perhaps mounting with a spec like "#l0" gets you a
specific device; maybe the spec should be a path
in the device tree like "/ether/0".)

Rfork(RFNODEV) (nee RFNOMNT) would cause exportdev
to fail, preventing access to devices not in the name space.

The underlying kernel interface to drivers would have to change --
they'd all need to process 9P messages, so probably there
would be a wrapper that let them be implemented in the
style they currently are.  But some devices (for example,
the disk devices) might choose to deal in 9P directly so that
they can access the request queue and perhaps behave
more efficiently.  If you're not careful there might be
problems with data getting copied more often than it
needs to.  For example right now I believe that a raw write
to the screen image via /dev/draw copies from the user
space buffer directly into video memory.  It would be
unfortunate if we lost that (though loadimage does its
own user-space copy first anyway).

Russ

Re: [9fans] A proposal regarding # in bind

[Boyd Roberts]

Russ Cox wrote:

>Here's a different proposal, also just an idea rather
>than a complete proposal, but perhaps worth pursuing.
>
>
Yes I was thinking of a similar (non file-system) interface
that provided a descriptor to access/modify your namespace.

Your idea certainly seems to be on the right track.

I would imagine that if it's a fd it could then be used
to pass a namespace to related and un-related processes.

Re: [9fans] A proposal regarding # in bind

[Ronald G. Minnich]

On Wed, 26 Feb 2003, Boyd Roberts wrote:

> Russ Cox wrote:
>
> >Here's a different proposal, also just an idea rather
> >than a complete proposal, but perhaps worth pursuing.
> >
> >
> Yes I was thinking of a similar (non file-system) interface
> that provided a descriptor to access/modify your namespace.
>
> Your idea certainly seems to be on the right track.
>
> I would imagine that if it's a fd it could then be used
> to pass a namespace to related and un-related processes.

This is actually how I did the old v9fs on Linux. To create a name space
you opened a "thing" that gave you an fd -- essentially the equivalent of
the mount device. To create other things (directories to mount things in,
etc.) in the name space you did ioctl (sorry, it was all I had) that set
up unions, mountpoints, etc., etc. To turn one of these off you closed the
fd for the corresponding thing, and it got removed from your name space.

Inheritance was easy. If you left the fd open for the kid, kid gets
namespace. If you didn't leave the fd open, kid gets clean name space.

It is pretty handy. The only issue is working out "what fd is what thing"
and I never had the time to make that easily figured out by users -- hence
I did not get to an equivalent of the ns command.

It all went away in the name of simplicity when we ported to 2.4, but I
still miss it sometimes!

ron

[9fans] A proposal regarding # in bind

[Joel Salomon]

How about /# ?
Where is the inferno group Martin said he cross-posted to?
comp.os.inferno seems to be a low traffic spam board.

--Joel

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Mon, 24 Feb 2003 14:25:41 -0500 (EST) Joel Salomon <salomo3@cooper.edu> wrote:
> How about /# ?
> Where is the inferno group Martin said he cross-posted to?
> comp.os.inferno seems to be a low traffic spam board.
>
> --Joel
>

There is a group on topica. I think this is meant to be the current group, since
it was active in January. I cross-posted my article to 'inferno@topica.com', and the
list's homepage is at:
	http://www.topica.com/lists/inferno/

However, my attempts to (re-)subscribe have either been unsuccessful, or
there is something wrong with the list, since I haven't received my message
back from the list yet! (Is it moderated my someone who is on holiday, perhaps? :-)

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[rog]

rob:
> Your proposal is interesting but doesn't solve the bootstrap problem.
> How would /proto get mounted?  You see, the thing about # names
> is that they're really not in the name space, and that comes in handy
> when booting or creating a name space from scratch, such as in
> listen.  Since a program can't name the proto driver, how does one
> establish a connection to it?  I'm sure there's a way; I just wonder
> what your plan is.

two possibilities spring to mind:

a) there's still an escape from the namespace, but a smaller one:
there could be one (and only one) device nameable in the '#' name
space, the proto device.  (whether one allows an attach spec is a
matter of taste).  that at least would solve some of the naming
problems.

b) have a special system call for attaching proto.

martin:
> One could have a /proto/ctl file to which commands could be sent to remove
> (or even add?!) devices from the visibility of this, and inheriting, processes
> (a sort of fine-grained NODEVS).

this would require that the namespace served by the proto device
was specific to a namespace group. how would the proto device
know to serve the same namespace to a process that's just
done an rfork(RFNAMEG)?

you could make it so each attach to '#' (the proto device) gave
you a new instance of that device, so:

	unmount /proto
	bind '#' /proto

would allow changing of availability of devices in /proto
without affecting anything else.

Re: [9fans] A proposal regarding # in bind

[rob pike, esq.]

/proto is an odd choice of name and also kinda long.
/ur seems better.  one could have the ur-console /ur/console,
etc.

-rob

Re: [9fans] A proposal regarding # in bind

[Jack Johnson]

rob pike, esq. wrote:
> /proto is an odd choice of name and also kinda long.
> /ur seems better.  one could have the ur-console /ur/console,
> etc.

But then I'd have to name a host enlil and find a cuneiform font...

-J

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Mon, 24 Feb 2003 11:04:21 -0800 "rob pike, esq." <rob@mightycheese.com> wrote:
> /proto is an odd choice of name and also kinda long.
> /ur seems better.  one could have the ur-console /ur/console,
> etc.
>
> -rob
>

I didn't like 'proto' either, but coming up with a good name is even more
difficult than coming up with a good idea :-)!

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[chris]

Rather than rog's special special #name for acquiring the
local device namespace I'd prefer a syscall.

Things in the namespace (named by paths) can be anywhere
in the network.  Syscalls are tied to the local machine.
This seems conceptually cleaner.

Other notes:

pctl(NODEVS) still allows attach to certain devices such as devpipe
and prog.  Martin's unmount /ur would prevent an app from killing
off any spawned threads or using pipes, which seems draconian.

[NOTE: general access to prog is a problem anyway - consider multiple
users logged in as 'none' - any one can kill the threads of the others.]

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Tue, 25 Feb 2003 11:02:27 +0000 chris@cjl1.demon.co.uk wrote:
> Rather than rog's special special #name for acquiring the
> local device namespace I'd prefer a syscall.

Like I've said in another message, I'd prefer there to be no (user-visible)
way to mount /ur, only a way to unmount it!

>..
> Other notes:
>
> pctl(NODEVS) still allows attach to certain devices such as devpipe
> and prog.  Martin's unmount /ur would prevent an app from killing
> off any spawned threads or using pipes, which seems draconian.

Right. Now I understand the comments in another message...

How about this:
Before starting the init process, the kernel binds into init's namespace

	#/ onto /
	#smallur onto /ur
	#bigur onto /ur (BEFORE)

using the kernel's private, special version of bind, which does understand these names.

#smallur would provide names for '#|' etc, and #bigur would provide names
for the rest. Then an inheriting process could unmount bigur, but still be able
to create pipes, etc.

(NB I'm not seriously suggesting these exact names! :-)

BTW: why would my unmount /ur prevent an application from killing spawned
threads? If the application had #p mounted on /prog, then unmounting /ur wouldn't
affect that in any way.... (/ur is only used during the bind of #p etc.)

>
> [NOTE: general access to prog is a problem anyway - consider multiple
> users logged in as 'none' - any one can kill the threads of the others.]

Indeed!

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

> Like I've said in another message, I'd prefer there to be no (user-visible)
> way to mount /ur, only a way to unmount it!

How would you implement newns?

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Tue, 25 Feb 2003 09:11:46 -0500 "Russ Cox" <rsc@plan9.bell-labs.com> wrote:
> > Like I've said in another message, I'd prefer there to be no (user-visible)
> > way to mount /ur, only a way to unmount it!
>
> How would you implement newns?
>

Newns should only work if /proto is mounted, right? Just like it shouldn't work
after a pctl(NODEVS). Or is newns more powerful than I had appreciated?

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

> Newns should only work if /proto is mounted, right? Just like it shouldn't work
> after a pctl(NODEVS). Or is newns more powerful than I had appreciated?

Newns builds a new name space from scratch.  The implementation
is in /sys/src/libauth/newns.c.

Once newns opens the file describing the name space it is
to construct, it clears the name space with rfork(RFNAMEG)
and then starts rebuilding.  If rfork(RFNAMEG) doesn't clear
/ur, then /ur is still a special case.  If it does clear /ur, then
how do you get it back?

Russ

Re: [9fans] A proposal regarding # in bind

[Russ Cox]

> Newns should only work if /proto is mounted, right? Just like it shouldn't work
> after a pctl(NODEVS). Or is newns more powerful than I had appreciated?

[RFCNAMEG not RFNAMEG]

Newns builds a new name space from scratch.  The implementation
is in /sys/src/libauth/newns.c.

Once newns opens the file describing the name space it is
to construct, it clears the name space with rfork(RFCNAMEG)
and then starts rebuilding.  If rfork(RFCNAMEG) doesn't clear
/ur, then /ur is still a special case.  If it does clear /ur, then
how do you get it back?

Russ

Re: [9fans] A proposal regarding # in bind

[Ronald G. Minnich]

possibly me being a stick-in-the-mud, but so far the /ur ideas seem to be
adding new rules with special cases, mountpoints that happen in magic
ways, exceptions to things that shouldn't have exceptions (newns), and so
on. It's also adding two "special" names (/ur and #) where there used to
be one.

So far the simplicity of # seems a bit nicer.

ron

Re: [9fans] A proposal regarding # in bind

[northern snowfall]

>
>
>It's also adding two "special" names (/ur and #) where there used to
>be one.
>
>So far the simplicity of # seems a bit nicer.
>
Agreed. A nexus isn't composed of multiple parts. A nexus should be just
that,
a single access endpoint. Though '#' may be "clunky" it works well and is
simple. I like the idea of device names rather than Runes, but, it seems
that
/ur /whatever and whatnots are even worse hacks over complicating the
issue, rather than creating a solid solution.
Don

>

Re: [9fans] A proposal regarding # in bind

[Dan Cross]

> > Newns should only work if /proto is mounted, right? Just like it shouldn't work
> > after a pctl(NODEVS). Or is newns more powerful than I had appreciated?
>
> [RFCNAMEG not RFNAMEG]
>
> Newns builds a new name space from scratch.  The implementation
> is in /sys/src/libauth/newns.c.
>
> Once newns opens the file describing the name space it is
> to construct, it clears the name space with rfork(RFCNAMEG)
> and then starts rebuilding.  If rfork(RFCNAMEG) doesn't clear
> /ur, then /ur is still a special case.  If it does clear /ur, then
> how do you get it back?

Hmm.  I wonder if one can post a file descriptor for a kernel
device under /ur ala what srv does.  Then, newns() could simply
open that file descriptor, clear the namespace, and then mount
it.  That's not shockingly different from what we do now.

Similarly, the bootstrapping case could be handled by having the
kernel pass init() an open file descriptor, which it could mount
on /ur.  I'm not so concerned about being able to remount it in
a process (or descendent thereof) that's unmounted it, so I see
little difference between ``bigur'' and ``smallur''.  If you
want /proc, mount it.  If you want #|, mount it somewhere, then
do your unmount.  Environment's might be a little wierd to deal
with, though.

	- Dan C.

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Tue, 25 Feb 2003 11:49:59 -0500 Dan Cross <cross@math.psu.edu> wrote:
> > > Newns should only work if /proto is mounted, right? Just like it shouldn't work
> > > after a pctl(NODEVS). Or is newns more powerful than I had appreciated?
> >
> > [RFCNAMEG not RFNAMEG]
> >
> > Newns builds a new name space from scratch.  The implementation
> > is in /sys/src/libauth/newns.c.

Right. I forgot about RFCNAMEG, and assumed that it just read /prog/pid/ns
and unmounted it found there! But...

> > Once newns opens the file describing the name space it is
> > to construct, it clears the name space with rfork(RFCNAMEG)
> > and then starts rebuilding.  If rfork(RFCNAMEG) doesn't clear
> > /ur, then /ur is still a special case.  If it does clear /ur, then
> > how do you get it back?
>
> Hmm.  I wonder if one can post a file descriptor for a kernel
> device under /ur ala what srv does.  Then, newns() could simply
> open that file descriptor, clear the namespace, and then mount
> it.  That's not shockingly different from what we do now.

This sounds neat to me. It's not really a special case any more, just
the application of a general mechanism. (I don't like special cases
either! :-)

> Similarly, the bootstrapping case could be handled by having the
> kernel pass init() an open file descriptor, which it could mount
> on /ur.  I'm not so concerned about being able to remount it in
> a process (or descendent thereof) that's unmounted it, so I see
> little difference between ``bigur'' and ``smallur''.  If you
> want /proc, mount it.  If you want #|, mount it somewhere, then
> do your unmount.  Environment's might be a little wierd to deal
> with, though.

Agreed! That was exactly my point of view too - I only suggested smallur
to show that there are several possible approaches.

>
> 	- Dan C.
>

Re: /ur introducing more special cases than it removes: I believe
that most of the new special cases are to continue the support for
the old '#' syntax. During the transition period, there would of course
be more complications, since both the old and the new syntaxes
have to work simultaneously!

However, once backwards compatibility for '#' could be removed
completely, then using Dan's suggestion, I would have thought the
'/ur' approach would be gloriously free of special cases (except
perhaps, the fact that init is spawned with an open file descriptor).

Anyway, the whole thing was just a suggestion/idea/question, and the
discussion has been educational for me, at least. (It sure beats spam
and "how do we avoid spam" messages, however important the later
might be! :-)

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[Fco.J.Ballesteros]

An alternative to having a special system call
could be for RFCNAMEG to mean `a namespace with just
a reasonable set of kernel devices mounted under /ur'.


There'd be no bootstrap problem (well, it would be hidden inside the code
for RFCNAMEG).

This alternative would lead to:

1. the problem of using just some of the devices and not
all of them.

2. the problem of `which one is the reasonable set' (eg. we probably
dont want #| there for each RFCNAMEG).

If the implementation of RFCNAMEG becomes just a bunch of attach calls
to the set of `reasonable' # names, and we permit unmount on, say, /ur/console
then I'd say that 1 is not a problem.

Regarding 2, I don't have an answer (other than keeping #| or changing
its semantics---eg. creating pipes by cloning and not by attaching).

Re: [9fans] A proposal regarding # in bind

[George Michaelson]

well either /// or /... spring to mind as precedents

(newcastle connection)

-George

Re: [9fans] A proposal regarding # in bind

[Bruce Ellis]

Research Inferno has an "indirect driver" which provides
attach by name rather than magic rune.  It's magic rune
is * and the mount spec is the name of the sought driver.

'#*cons' is equivalent to '#c'

This makes scripts and startup code a lot easier to follow,
and ns files clearer.  e.g.

    bind -a '#*kprof' /dev

It also makes dynamically loadable device drivers with
autoallocated magic runes more manageable.

brucee

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Tue, 25 Feb 2003 10:32:20 +1100 "Bruce Ellis" <brucee@chunder.com> wrote:
> Research Inferno has an "indirect driver" which provides
> attach by name rather than magic rune.  It's magic rune
> is * and the mount spec is the name of the sought driver.
>
> '#*cons' is equivalent to '#c'
>

Ahh! It's rather funny that I didn't know that!

> This makes scripts and startup code a lot easier to follow,
> and ns files clearer.  e.g.
>
>     bind -a '#*kprof' /dev
>
> It also makes dynamically loadable device drivers with
> autoallocated magic runes more manageable.

Indeed!

> brucee

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[chris]

On Tue, 25 Feb 2003 10:32:20 +1100 "Bruce Ellis" <brucee@chunder.com> wrote:
> Research Inferno has an "indirect driver" which provides
> attach by name rather than magic rune.  It's magic rune
> is * and the mount spec is the name of the sought driver.
>
> '#*cons' is equivalent to '#c'
>

can you ls '#*' to get a list of devices or do you still
have to cat /dev/drivers ?

Also, you've reminded me of the use of attach name in several of
the drivers (e.g. kfs).
How do you get an attach name to an underlying device attached
through '#*' when you are using the attach name to
identify the device?

This is also an issue for Martin's "/ur" scheme.
The # namespace partitions the initial path element into
device id (letter) and attach name, which is used to paramaterise
the particular instance of the driver in the namespace.
There seems no way of paramaterising device instances in
Martin's scheme as there is only ever one instance or am I
missing something?

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Tue, 25 Feb 2003 11:19:57 +0000 chris@cjl1.demon.co.uk wrote:
>...
> Also, you've reminded me of the use of attach name in several of
> the drivers (e.g. kfs).
> How do you get an attach name to an underlying device attached
> through '#*' when you are using the attach name to
> identify the device?
>
> This is also an issue for Martin's "/ur" scheme.
> The # namespace partitions the initial path element into
> device id (letter) and attach name, which is used to paramaterise
>...

No, I dealt with this when I suggested that '#Dppp/path' would expand
to '/proto/shortnames/D/ppp/path'. Of course, this requires some,
(perhaps unusually clever) path processing in the proto/ur driver, but who's
saying it can't be clever :-) ?!

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[Bruce Ellis]

> How do you get an attach name to an underlying device attached
> through '#*' when you are using the attach name to
> identify the device?

The Research Inferno devindir uses the syntax:

    name [ ! spec ]

So ...

    #*cons  == #c
    #*ether!0 == #l0
    #*ip!1 == #I1
    #*srv!auth == #sauth

etc. Note that the driver is very simple. The only code involved is
in indirattach() which smashes the spec, scrounges thru devtab,
and calls the appropriate attach.  Nothing else was changed.

brucee

Re: [9fans] A proposal regarding # in bind

[Skip Tavakkolian]

> So ...
>
>     #*cons  == #c
>     #*ether!0 == #l0
>     #*ip!1 == #I1
>     #*srv!auth == #sauth
>

I like '#*' idea.

In the interest of considering all possibilities, I was looking up QNX's
idea of a node, and its notation which is '//n' where n == 0 means
local node.  QNX's idea is "the namespace rooted at node n", where
nodes ids are statically assigned by administrator, so not directly
comparable to '#'.  But if there was a way to dynamically define
ids for known resource locations, then //n could be used to mean
the same thing as '#' on machine n.
example:
	//0/	== #/
	//n/cons	== #c on machine n
	etc.

Just a thought.

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Mon, 24 Feb 2003 19:04:01 0000 rog@vitanuova.com wrote:
>...
>
> a) there's still an escape from the namespace, but a smaller one:
> there could be one (and only one) device nameable in the '#' name
> space, the proto device.  (whether one allows an attach spec is a
> matter of taste).  that at least would solve some of the naming
> problems.
>
> b) have a special system call for attaching proto.

I was hoping to avoid any visibility from user space of the mechanism
for attaching /proto. (See my reply to Rob's message)

>
> martin:
> > One could have a /proto/ctl file to which commands could be sent to remove
> > (or even add?!) devices from the visibility of this, and inheriting, processes
> > (a sort of fine-grained NODEVS).
>
> this would require that the namespace served by the proto device
> was specific to a namespace group. how would the proto device
> know to serve the same namespace to a process that's just
> done an rfork(RFNAMEG)?

Ahh yes - good point. That's one reason why I said that it may be going
too far!


> you could make it so each attach to '#' (the proto device) gave
> you a new instance of that device, so:
>
> 	unmount /proto
> 	bind '#' /proto
>
> would allow changing of availability of devices in /proto
> without affecting anything else.
>

See above....

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

[9fans] A proposal regarding # in bind

[Martin C.Atkins]

Hi,
	One thing I have never quite felt comfortable with in Plan9
and Inferno, is the special treatment of '#' in the bind system call,
and more generally, at the start of any path given to open, etc.
(The following discussion uses Inferno examples, but most have direct
Plan9 equivalents. I've cross-posted this to both groups, since it is
a question about both systems - I hope that is OK!)

Problems I see with '#' include:
It is a special case:
	Nowhere else is there a similar mechanism/convention.

Limited:
	What happens when we run out of letters/glyphs to represent devices?
	(Ok, so there *are* 65,000-odd glyphs... :-)

Awkward:
	Many device letters are no-longer obvious. E.g. Many devices could
	reasonably be #s - SCSI, serial, etc. Oops, no it's srv!
	Is #d a disk, or /dev/draw?
	Why is flash '#W'? Why is ssl '#D'? (Because '#s' is srv perhaps?)

Breaks the rules in 'The Hideous Name':
	why can't I do:
		ls -l #?
	to see all the devices, etc...

Requires other special cases:
	Such as the sys-pctl option, NODEVS.

I think I have a proposal that could replace this mechanism, addressing all
these problems, while providing a (reasonably) clean backwards compatibility option
until the rest of the system caught up.

I propose a special filesystem driver, call it 'proto', which is mounted
on /proto by the kernel, during the creation of the first, 'init', process
from which all the others are derived by forking.
The /proto directory would contain a file for each device, so that instead
of
	bind '#c' ...
one would do
	bind '/proto/console' ...
(or "bind '/proto/cons' ...", if you must insist :-)

The special behaviour of proto, would be that attempts to bind files within
it would do what binds of names beginning with '#' currently do.

Then one could:
	ls -l /proto
to see the devices on this system.

But lots of programs have "#..." filenames in them, so what about them?
While such programs continue to exist, system calls would be changed so that '#x'
at the start of a filename would be expanded to:
	/proto/shortnames/x
The "shortnames" directory would contain the single letter pseudonyms for the drivers.
Furthermore, "bind '#Dppp/path' ..." would be rewritten to:
	bind '/proto/shortnames/D/ppp/path' ...

So that the example from KFS(3):
	echo filsys fs kfs.file >'#Kcons/kfsctl'
would be equivalent to:
	echo filsys fs kfs.file >'/proto/shortnames/K/cons/kfsctl'
or, to:
	echo filsys fs kfs.file >'/proto/kfs/cons/kfsctl'

(
	bind '#D/path' ...
could map to:
	bind '/proto/shortnames/D/./path' ...
or are there any better suggestions? Would
	bind '/proto/shortnames/D//path' ...
actually be safe enough?)

Once drivers are represented by files, lots of other things become possible
(although some of these might be going too far...)

Access to devices could be controlled by permissions, etc.

One could have a /proto/ctl file to which commands could be sent to remove
(or even add?!) devices from the visibility of this, and inheriting, processes
(a sort of fine-grained NODEVS).

"sys->pctl(NODEVS, [])" itself could be replaced by:
	unmount /proto
since there is no way for a program to name the proto driver, there is
then no way to get access to it once it has been unmounted, or to gain
access to any other devices! '#' names would expand into non-existent paths.

This all seems so obvious, that I can't understand why it hasn't always
been done this way!

I'm sure that there would be many practical issues to sort out in
changing to this kind of scheme. One problem that springs to mind is
the format of /prog/pid/ns, and programs that read it...

But are there any fundamental problems with this approach? Was there some
clever reason why this wasn't done from the start, or would cause untold
problems that I haven't thought of?

I.e. Am I missing something, or is it a 'good idea' (that might be
too much trouble to change for now)?

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com

Re: [9fans] A proposal regarding # in bind

[Boyd Roberts]

Martin C.Atkins wrote:

>Problems I see with '#' include:
>It is a special case:
>	Nowhere else is there a similar mechanism/convention.
>
Yup, it _is_ a special case.

Re: [9fans] A proposal regarding # in bind

[rob pike, esq.]

# file names were just a hack to get started - literally to get started.
They were a place holder until a better idea came along.  None has.

# was never considered a great idea; I just needed some way to
name an unnamed resource.  I deliberately chose # as the character
because it's the comment character in the shell and therefore is
really irritating to use.

Your proposal is interesting but doesn't solve the bootstrap problem.
How would /proto get mounted?  You see, the thing about # names
is that they're really not in the name space, and that comes in handy
when booting or creating a name space from scratch, such as in
listen.  Since a program can't name the proto driver, how does one
establish a connection to it?  I'm sure there's a way; I just wonder
what your plan is.

One thing I like about your proposal is that it would make it easier
to import devices from remote machines.  One thing I don't like
about your proposal is that it would make it easier to import
devices from remote machines.

> This all seems so obvious, that I can't understand why it hasn't always
> been done this way!
Many years of thinking, especially when given the ideas made possible
by the incomplete early implementations, can make hard things obvious.

-rob

Re: [9fans] A proposal regarding # in bind

[Martin C.Atkins]

On Mon, 24 Feb 2003 10:36:42 -0800 "rob pike, esq." <rob@mightycheese.com> wrote:
> # file names were just a hack to get started - literally to get started.
> They were a place holder until a better idea came along.  None has.

Ah good - I'm not missing something obvious!

>
> # was never considered a great idea; I just needed some way to
> name an unnamed resource.  I deliberately chose # as the character
> because it's the comment character in the shell and therefore is
> really irritating to use.

:-)

I had wondered about how important it was to you that the '#' namespace
was 'outside' the normal one, but given that things like:
	echo filsys fs kfs.file >'#Kcons/kfsctl'
work, it doesn't seem to me to be such a separate namespace as might be.

> Your proposal is interesting but doesn't solve the bootstrap problem.
> How would /proto get mounted?  You see, the thing about # names
> is that they're really not in the name space, and that comes in handy
> when booting or creating a name space from scratch, such as in
> listen.  Since a program can't name the proto driver, how does one
> establish a connection to it?  I'm sure there's a way; I just wonder
> what your plan is.

I thought I *had* addressed the bootstrap problem, but obviously it was not
clear.

I was remembering the new code for startboot that Russ posted on 24th Jan:

> void
> startboot(char *argv0, char **argv)
> {
>         open(cons, OREAD);
>         open(cons, OWRITE);
>         open(cons, OWRITE);
>         bind(c, dev, MAFTER);
>         bind(ec, env, MAFTER);
>         bind(e, env, MCREATE|MAFTER);
>         bind(s, srv, MREPL|MCREATE);
>         exec(boot, argv);
>         for(;;);
> }

and thinking that the proto driver could be bound by some *internal* magic
during the construction of the process before startboot gets started. Thus
it should be inherited by every process that hasn't had a parent do "unmount /proto".

NB. I don't know any of the details about how this first process gets started
(I haven't looked!), and so have no idea how easy/horrible this might be.
I am also assuming that all processes are ultimately children of this first
process, a la Unix. I hope this is clear now.

I did think that having this 'hack' in one place, and not using a system call or other
special mechanism from user space would be good for being absolutely certain
of the security of "unmount /proto".

>
> One thing I like about your proposal is that it would make it easier
> to import devices from remote machines.  One thing I don't like
> about your proposal is that it would make it easier to import
> devices from remote machines.

Yes, I thought about this... both the pros and the cons!

> > This all seems so obvious, that I can't understand why it hasn't always
> > been done this way!
> Many years of thinking, especially when given the ideas made possible
> by the incomplete early implementations, can make hard things obvious.

and obvious things hard? Yes - I've been there! :-)

> -rob
>

Martin
--
Martin C. Atkins				martin@mca-ltd.com
Mission Critical Applications Ltd, U.K.		http://www.mca-ltd.com