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

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] lpdaemon probs

[Conor Williams]

got acd working successfully through acme -
I like the interface - have my big stereo hooked up
to the cd drive and line in on and it sounds pretty good!

having problems with lpdaemon at the mo - getting a
read error: connection lost
in the log file when I connect using
aux/lpdsend -d myibm -H 10.5.1.20 india18 /tmp/blah
or when I set up a new printer which points to myibm
and print using
lp -d myibmremote /tmp/blah
myibm works fine from india18
/tmp/blah is only a small 4 line txt file which prints fine from
india18
tx
will551

Re: [9fans] lpdaemon probs

[Geoff Collyer]

lp is complicated.  What are the entries in /sys/lib/lp/devices for
your printers?

Re: [9fans] lpdaemon probs

[Conor Williams]

ok...
dont have the file with me but its something like:
myibm             -                 -            -             /dev/lp2data
gs!laserjet!?    nospool    - - - -
# this line isnt quite it but is working perfectly on india18
myibmremote india18    india18 myibm   -                        post+nohead
lpdaemon lpd - -  FIFO
# this line isnt quite it but the log for the lpdaemon on india18 is showing
a connection
# but then I get the read error: connection lost line...
# lpdaemon- just calls aux/lpdsend (it was already there in the spool dir)
# lpd is used for the stats...
# I get a very similar error when I use aux/lpdsend directly bypassing the
above line
# for myibmremote
#
I traced some of the code for the lpdaemon on port 515 - could it be that it
doesnt have permissions somewhere?
l8r
will551


> lp is complicated.  What are the entries in /sys/lib/lp/devices for
> your printers?
>
>

Re: [9fans] lpdaemon probs

[Geoff Collyer]

I think we need your /sys/lib/lp/devices file (or at least the entries
relevant to your printers), not an approximation, to debug this.
There should be a dozen fields in most entries; they should look
something like this (all one line):

fn			2C-501	olive.cs.bell-labs.com	tcp!fn.cs.bell-labs.com!9100 81920	post+600dpi+duplex+hp4simx	generic	generic	generic	generic		tcppost	FIFO

Also, could you run this and send us the output:

flag x +
echo fs $fs fileserver $fileserver
9fs other
ls -ld /lp /n/other/lp

Re: [9fans] lpdaemon probs (fix)

[Conor Williams]

hey Geoff
thanks for youre interest...
got it running last night - spent half the night hacking the
lpdaemon.c code (/root/sys/src/cmd/lp) and traced the problem
to the fork and exec - which didnt seem to be running - so ran
touch and that worked then watched the processes being spawned on
the server and found that lp was being spawned...
so eventually after trying differnt things traced the problem to the
namespace... what happened was the parallel port wasnt bound for
user none coming into the box...
so  a bind -a '#'L2 /dev in the /rc/bin/service/tcp515 file before the
lpdaemon line fixed it... jumping around the room last night!! This
fixed the "read error: connection lost line" aswell! So I can now print from
my diskless terminal to my server which has the printer hanging out
of its parallel port.
Q. Has no-one come across that before?
The devices file I had created was actually ok (it is quite similar to
the one I posted)
l8r
will551

----- Original Message -----
From: "Geoff Collyer" <geoff@collyer.net>
To: <9fans@cse.psu.edu>
Sent: Tuesday, February 25, 2003 11:50 PM
Subject: Re: [9fans] lpdaemon probs


> I think we need your /sys/lib/lp/devices file (or at least the entries
> relevant to your printers), not an approximation, to debug this.
> There should be a dozen fields in most entries; they should look
> something like this (all one line):
>
> fn          2C-501  olive.cs.bell-labs.com  tcp!fn.cs.bell-labs.com!9100
81920  post+600dpi+duplex+hp4simx  generic generic generic generic
tcppost FIFO
>
> Also, could you run this and send us the output:
>
> flag x +
> echo fs $fs fileserver $fileserver
> 9fs other
> ls -ld /lp /n/other/lp
>
>

Re: [9fans] lpdaemon probs (fix)

[Geoff Collyer]

Ah, yes, I have run into that in the past.  It only matters if you
have a parallel-port printer.  It might be worth a mention in the
installation notes.