[9fans] A proposal regarding # in bind
Martin C.Atkins
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 mar...@mca-ltd.com
Mission Critical Applications Ltd, U.K. http://www.mca-ltd.com
Boyd Roberts
>Problems I see with '#' include:
>It is a special case:
> Nowhere else is there a similar mechanism/convention.
>
Yup, it _is_ a special case.
Bruce Ellis
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
Martin C.Atkins
>...
>
> 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 C.Atkins
> /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 C.Atkins
> # 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 C.Atkins
> 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 C.Atkins
> 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 'inf...@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? :-)
Jack Johnson
> /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
ch...@cjl1.demon.co.uk
On Tue, 25 Feb 2003 10:32:20 +1100 "Bruce Ellis" <bru...@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?
Russ Cox
> 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
Russ Cox
> 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
Ronald G. Minnich
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
Martin C.Atkins
> 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 C.Atkins
> > 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!
>
>
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
George Michaelson
well either /// or /... spring to mind as precedents
(newcastle connection)
-George
Dan Cross
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.
Martin C.Atkins
>...
> 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 :-) ?!
ch...@cjl1.demon.co.uk
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
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.
>
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
>
rob pike, esq.
/ur seems better. one could have the ur-console /ur/console,
etc.
-rob
r...@vitanuova.com
> 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
Joel Salomon
Fco.J.Ballesteros
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).
rob pike, esq.
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
Russ Cox
> way to mount /ur, only a way to unmount it!
How would you implement newns?
Bruce Ellis
> 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
Skip Tavakkolian
>
> #*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.
oka...@granite.cias.osakafu-u.ac.jp
>>
>> #*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
Martin C.Atkins
> > > 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! :-)
Digby Tarvin
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 dig...@acm.org
http://www.cthulhu.dircon.co.uk
Russ Cox
> 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.
Russ Cox
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
Boyd Roberts
>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.
r...@vitanuova.com
> 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...
Russ Cox
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.
Ronald G. Minnich
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
John Stalker
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
a...@9srv.net
then again, perhaps port/master should be up to date?
ア
Russ Cox
it is.
a...@9srv.net
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.
ア
Sam
we doing on (un)loadable device drivers? Wasn't
someone working on that?
Cheers,
Sam
Fco.J.Ballesteros
> 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.
Bruce Ellis
> we doing on (un)loadable device drivers? Wasn't
> someone working on that?
I did it for Research Inferno. Works well. You'll find
that 5l and el have the right options. I did 8l first but it
ain't in the tree.
brucee