Re: [9fans] directly opening Plan9 devices
arm has virtualization? Some do. ARMs are so cheap ... don't jail things, just get another one. i wasn't aware of that. so for my arm http/ftp server, you suggest one physical cpu for each http/ftp connection? how do i route the connections? - erik
Re: [9fans] directly opening Plan9 devices
i wasn't aware of that [ARM with virtualisation]. it's a little misleading: it's just another option in the ARM set, and fairly recent at that. whatever it is, yours probably hasn't got it, but it can take a little while to work that out.
Re: [9fans] directly opening Plan9 devices
On Thu, Jan 8, 2009 at 5:37 AM, erik quanstrom quans...@quanstro.net wrote: arm has virtualization? Some do. ARMs are so cheap ... don't jail things, just get another one. i wasn't aware of that. so for my arm http/ftp server, you suggest one physical cpu for each http/ftp connection? how do i route the connections? maybe you could hire one of those old Bell System operators to move phone jacks around. Not sure on that one :-) If you want what a jail does, I still think there are better ways on ARM, esp. watching this conversation: - something the equivalent of user mode linux - or run a plan 9 kernel per http, under something like 9vx - or something like lguest or other paravirt support Just looking at all the mods people want for jails, these almost seem like less work. ron
Re: [9fans] directly opening Plan9 devices
If you want what a jail does, I still think there are better ways on ARM, esp. watching this conversation: - something the equivalent of user mode linux - or run a plan 9 kernel per http, under something like 9vx - or something like lguest or other paravirt support Just looking at all the mods people want for jails, these almost seem like less work. um, reductum ad absurdum? - erik
Re: [9fans] directly opening Plan9 devices
Just looking at all the mods people want for jails, these almost seem like less work. i don't think so: i think it wouldn't be hard for simple changes to address it. it's better than pushing the problem to a lower level that's even less able to solve it well (or really just reintroduces the problem at that level).
Re: [9fans] directly opening Plan9 devices
On Thu, 2009-01-08 at 07:36 -0800, ron minnich wrote: If you want what a jail does, I still think there are better ways on ARM, esp. watching this conversation: - something the equivalent of user mode linux This one sounds like a waste for a system that is so close to supporting proper jailing in the first place. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
On Wed, 2009-01-07 at 08:55 -0800, ron minnich wrote: The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? Well, as was pointed out before -- not all hardware supports virtualization. And it would be a mistake to stick a virtualization layer into every bit of silicone. The discussion here is really about one kernel vs. many. Hardware not being able to run many gives you one constraint. Another issue is that many kernels don't share anything unless explicitly told so. A single kernel have access to everything and thus needs to be explicitly told when access to resources is NOT to be granted. Just two ways to think about it. Don't know which one is better. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
On Tue, 2009-01-06 at 09:17 -0500, erik quanstrom wrote: i think we can skip the sematic arguments and the questions about rooting. let's go directly to how would you unify the big-n Namespace in a way that's clearly better? At this point: I don't know. :-( The discussion was tremendously useful for me, though. I can only hope it was also moderately entertaining for the rest of the list. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron
Re: [9fans] directly opening Plan9 devices
On Wed Jan 7 11:58:04 EST 2009, rminn...@gmail.com wrote: The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron arm has virtualization? - erik
Re: [9fans] directly opening Plan9 devices
On Wed, Jan 7, 2009 at 9:16 AM, erik quanstrom quans...@coraid.com wrote: On Wed Jan 7 11:58:04 EST 2009, rminn...@gmail.com wrote: The underlying assumption of motivation for this discussion is that jailing (or whatever we want to call it) is somehow a good thing. Given that every CPU we care about comes with virtualization hardware, I just can't see the point of jails -- seems like an idea whose time has gone, kind of like 8086 segments. If we give up on using RFNOMNT as a jailing mechanism, do the concerns really make any sense? ron arm has virtualization? Some do. ARMs are so cheap ... don't jail things, just get another one. ron
Re: [9fans] directly opening Plan9 devices
And just to be completely clear: the #X notation doesn't bother me when #X can be thought of as a weird cousin of '/srv/#X'. Both are simply channels that need to be not really. #X references a device directly. (hence the attach you were complaining about.) there is no channel. we could argue semantics, but it's not part of the namespace structure, so i don't think it's part of any namespace. /srv/whatever is the opposite. there is no direct device reference, there is a channel and it is part of the pg's namespace. i think we can skip the sematic arguments and the questions about rooting. let's go directly to how would you unify the big-n Namespace in a way that's clearly better? - erik
Re: [9fans] directly opening Plan9 devices
Things like term% cd '#|' term% pwd #| just don't seem right. you ask for fish; you get fish. what's the trouble?
Re: [9fans] directly opening Plan9 devices
On Jan 5, 2009, at 3:00 AM, Charles Forsyth wrote: Things like term% cd '#|' term% pwd #| just don't seem right. you ask for fish; you get fish. what's the trouble? I supposed this is a matter of taste. There's as little trouble with the above as with //foo != /foo on certain legacy systems. Or, as was pointed out by Roman Z, with MS-DOS drive nomenclature. They all work fine. Yet, the closer I can get to a single namespace rooted at / the better I feel. With #X I get at least two: one rooted at / and the other one rooted at #. And just to be completely clear: the #X notation doesn't bother me when #X can be thought of as a weird cousin of '/srv/#X'. Both are simply channels that need to be mounted in order for the file hierarchy to appear. See, I would go even as far as to say that, even though I know there's no 9P involved with #X, I wouldn't mind at all if open(#X, ORDWR) gave me an illusion of 9P messages being exchanged. The implicit attach that happens behind my back when I access #X/foo is what makes me cringe. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
Seems that despite the many years of thinking, this is still a tricky problem, and # has turned out to be 'good enough' to keep any alternative from appearing. A judgement call, no doubt. But the list of failings doesn't seem very long to me. I'd say that having a /dev pre-built into the kernel is far worse. And inadequate. ++L
Re: [9fans] directly opening Plan9 devices
No one has yet offered a working, cleaner idea. I think it is a working, perfectly clean idea, myself. It's a namespace of its own and there are only a very few inconsistencies within it, well justified by the very nature of the namespace. That minor nits such as #s and #| being a bit off the paradigm apply suggests that some aspects could be given more thought, but they do not invalidate the usefulness and consistency of the design. Rather, they show a surprising maturity for something that probably did not get too many iterations. ++L
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 23:01 -0800, Russ Cox wrote:
On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik r...@sun.com wrote:
[complaint about # names]
Please let me know what kind of keywords or emoticons I am supposed
to include in my emails to indicate that they are *not* complaints,
but rather invitations for a discussion.
No one has yet offered a working, cleaner idea.
Not to even suggest a 100% cleanliness, but simply
as a matter of incremental improvements here's one
simple idea.
Wouldn't the approach of treating #X as channels
instead of full fledged parallel namespace be at least
somewhat cleaner than what we have today? If the only
thing that any of the #X permitted was to issue a
mount/bind syscall, it would, IMHO, simplify and
clean at least the following areas:
1.1. the need for less than ideal special case in
namec():
switch(name[0]){
case '#':
Not that we would get rid of it 100%, but it seems
much more appropriate in bindmount()
1.2. the need for an implicit and poorly documented
and thus confusing -attach in namec():
switch(name[0]){
case '#':
.
c = devtab[t]-attach(up-genbuf+n);
1.3. an ability of userspace applications to bypass
the venerable namespace mechanics
The above seems like a net gain, doesn't it?
Thanks,
Roman.
Re: [9fans] directly opening Plan9 devices
On Sun, 2009-01-04 at 00:27 -0500, erik quanstrom wrote: Usign #X means doing a mount (you are attaching to the root of the driver's tree). You're right, of course. But it feels like a very special mount if one can refer to files served by the drivers directly through: '#X/bla-bla'. s/driver/file server/ there doesn't need to be any hardware involved. Well, that's part of the problem. I can't refer to things served by the actual 9P servers via something like /srv/sources/plan9. /srv/sources is a channel and as such it needs to be explicitly mounted before I can access what is being served by it. If all I could do with #X is to bind/mount it -- it would make a much more coherent model. From my point of view, of course. could you explain why you think this is special? I have nothing (major) against bind/mount interpreting names that start with # in a special way. I feel quite confused when namec() does that interpretation for a variety of system calls. Things like term% cd '#|' term% pwd #| just don't seem right. But let me ask you this in return: do you feel that constraining #X to bind/mount only would, actually, be worse compared to the behavior we have today? Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
I agree with Roman. When I open #X/path I feel like back to DOS. -- Roma
Re: [9fans] directly opening Plan9 devices
while replying to Nathaniel's post it dawned on me that something like this: open(#c/cons, OWRITE|OCEXEC); completely breaks the paradigm of namespaces. IOW, if I wanted to construct a namespace with a specially crafted server offering /dev/cons, the above would easily break out of that jail. see RFNOMNT in rfork(2). - erik
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote: while replying to Nathaniel's post it dawned on me that something like this: open(#c/cons, OWRITE|OCEXEC); completely breaks the paradigm of namespaces. IOW, if I wanted to construct a namespace with a specially crafted server offering /dev/cons, the above would easily break out of that jail. see RFNOMNT in rfork(2). Did you see the example I provided in the original email? rfork m is *exactly* RFNOMNT. And it doesn't seem to work for one simple reason: RFNOMNT doesn't restrict bind(2). So the question still stands. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
Did you see the example I provided in the original
email? rfork m is *exactly* RFNOMNT. And it doesn't
seem to work for one simple reason: RFNOMNT doesn't
restrict bind(2).
these are exceptions. from port/chan.c:
case '#':
nomount = 1;
up-genbuf[0] = '\0';
n = 0;
while(*name != '\0' (*name != '/' || n 2)){
if(n = sizeof(up-genbuf)-1)
error(Efilename);
up-genbuf[n++] = *name++;
}
up-genbuf[n] = '\0';
/*
* noattach is sandboxing.
*
* the OK exceptions are:
* | it only gives access to pipes you create
* d this process's file descriptors
* e this process's environment
* the iffy exceptions are:
* c time and pid, but also cons and consctl
* p control of your own processes (and unfortunately
* any others left unprotected)
*/
n = chartorune(r, up-genbuf+1)+1;
/* actually / is caught by parsing earlier */
if(utfrune(M, r))
error(Enoattach);
if(up-pgrp-noattach utfrune(|decp, r)==nil)
error(Enoattach);
t = devno(r, 1);
if(t == -1)
error(Ebadsharp);
c = devtab[t]-attach(up-genbuf+n);
break;
the first two indicated lines are redundant.
i'm not so sure about any of the exceptions.
- erik
Re: [9fans] directly opening Plan9 devices
Usign #X means doing a mount (you are attaching to the root of the driver's tree). However, for, drivers with letters |decp you can always attach to them no matter if RFNOMNT was used. Probably it was considered too restrictive not doing so, but that's IMHO. On Sat, Jan 3, 2009 at 10:56 PM, Roman V. Shaposhnik r...@sun.com wrote: On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote: while replying to Nathaniel's post it dawned on me that something like this: open(#c/cons, OWRITE|OCEXEC); completely breaks the paradigm of namespaces. IOW, if I wanted to construct a namespace with a specially crafted server offering /dev/cons, the above would easily break out of that jail. see RFNOMNT in rfork(2). Did you see the example I provided in the original email? rfork m is *exactly* RFNOMNT. And it doesn't seem to work for one simple reason: RFNOMNT doesn't restrict bind(2). So the question still stands. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
Did you see the example I provided in the original
email? rfork m is *exactly* RFNOMNT. And it doesn't
seem to work for one simple reason: RFNOMNT doesn't
restrict bind(2).
these are exceptions. from port/chan.c:
case '#':
nomount = 1;
up-genbuf[0] = '\0';
n = 0;
while(*name != '\0' (*name != '/' || n 2)){
if(n = sizeof(up-genbuf)-1)
error(Efilename);
up-genbuf[n++] = *name++;
}
up-genbuf[n] = '\0';
/*
* noattach is sandboxing.
*
* the OK exceptions are:
* | it only gives access to pipes you create
* d this process's file descriptors
* e this process's environment
* the iffy exceptions are:
* c time and pid, but also cons and consctl
* p control of your own processes (and unfortunately
* any others left unprotected)
*/
n = chartorune(r, up-genbuf+1)+1;
/* actually / is caught by parsing earlier */
if(utfrune(M, r))
error(Enoattach);
if(up-pgrp-noattach utfrune(|decp, r)==nil)
error(Enoattach);
t = devno(r, 1);
if(t == -1)
error(Ebadsharp);
c = devtab[t]-attach(up-genbuf+n);
break;
the first two indicated lines are redundant.
i'm not so sure about any of the exceptions.
Two comments:
0. First of all, thanks for the code snippet. I'm so used to Plan9
having as little exceptions as possible and being very well
documents that I sometimes forget to look for the source.
1. This better be documented in the man pages, if you ask me.
And finally, I'd say having these exceptions is a mistake. Unless,
there's a really good reason, they break the paradigm of RFNOMNT
quite needlessly without even a hint of a benefit.
Anybody disagrees?
Thanks,
Roman.
Re: [9fans] directly opening Plan9 devices
Isn't it too restrictive, eg, not allowing you to create pipes?
On Sat, Jan 3, 2009 at 11:40 PM, Roman V. Shaposhnik r...@sun.com wrote:
On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
Did you see the example I provided in the original
email? rfork m is *exactly* RFNOMNT. And it doesn't
seem to work for one simple reason: RFNOMNT doesn't
restrict bind(2).
these are exceptions. from port/chan.c:
case '#':
nomount = 1;
up-genbuf[0] = '\0';
n = 0;
while(*name != '\0' (*name != '/' || n 2)){
if(n = sizeof(up-genbuf)-1)
error(Efilename);
up-genbuf[n++] = *name++;
}
up-genbuf[n] = '\0';
/*
* noattach is sandboxing.
*
* the OK exceptions are:
* | it only gives access to pipes you create
* d this process's file descriptors
* e this process's environment
* the iffy exceptions are:
* c time and pid, but also cons and consctl
* p control of your own processes (and unfortunately
* any others left unprotected)
*/
n = chartorune(r, up-genbuf+1)+1;
/* actually / is caught by parsing earlier */
if(utfrune(M, r))
error(Enoattach);
if(up-pgrp-noattach utfrune(|decp, r)==nil)
error(Enoattach);
t = devno(r, 1);
if(t == -1)
error(Ebadsharp);
c = devtab[t]-attach(up-genbuf+n);
break;
the first two indicated lines are redundant.
i'm not so sure about any of the exceptions.
Two comments:
0. First of all, thanks for the code snippet. I'm so used to Plan9
having as little exceptions as possible and being very well
documents that I sometimes forget to look for the source.
1. This better be documented in the man pages, if you ask me.
And finally, I'd say having these exceptions is a mistake. Unless,
there's a really good reason, they break the paradigm of RFNOMNT
quite needlessly without even a hint of a benefit.
Anybody disagrees?
Thanks,
Roman.
Re: [9fans] directly opening Plan9 devices
Probably it was considered too restrictive not doing so, but that's IMHO.
there are suprisingly few uses of this. even nsec opens /dev/bintime
directly. none seem particularly compelling.
minooka; grep -n open `{find lib*|grep '\.[ch]$'}|grep '#[|decp]'
libc/9sys/getpid.c:11: f = open(#c/pid, 0);
libc/9sys/syslog.c:83: sl.consfd = open(#c/cons,
OWRITE|OCEXEC);
libc/9sys/sysname.c:13: f = open(#c/sysname, 0);
- erik
Re: [9fans] directly opening Plan9 devices
Isn't it too restrictive, eg, not allowing you to create pipes? pipes certianly are an exception. why can the others be bound for you if your jailer sees fit? - erik
Re: [9fans] directly opening Plan9 devices
And finally, I'd say having these exceptions is a mistake. Unless, there's a really good reason, they break the paradigm of RFNOMNT quite needlessly without even a hint of a benefit. so, it's likely that RFNOMNT was added and to avoid breaking too many things, a few exceptions were added with the intention of fixing and removing them. why don't you submit a patch to rfork(2)? - erik
Re: [9fans] directly opening Plan9 devices
On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom quans...@quanstro.net wrote: And finally, I'd say having these exceptions is a mistake. Unless, there's a really good reason, they break the paradigm of RFNOMNT quite needlessly without even a hint of a benefit. so, it's likely that RFNOMNT was added and to avoid breaking too many things, a few exceptions were added with the intention of fixing and removing them. i don't see why that's likely. maybe those were simply judged to be the safe set of devices. russ
Re: [9fans] directly opening Plan9 devices
And finally, I'd say having these exceptions is a mistake. Unless, there's a really good reason, they break the paradigm of RFNOMNT quite needlessly without even a hint of a benefit. so, it's likely that RFNOMNT was added and to avoid breaking too many things, a few exceptions were added with the intention of fixing and removing them. i don't see why that's likely. maybe those were simply judged to be the safe set of devices. for my part, i don't see why one would make it impossible to restrict those devices. (#| excepted, of course.) - erik
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 23:46 +0100, Francisco J Ballesteros wrote: Isn't it too restrictive, eg, not allowing you to create pipes? It depends. The point, however, is that NOT allowing to restrict *all* attaches seem far more restrictive. ;-) Besides, my main concern is not about restricting at all. But rather about diverting all traffic to the filter fs. So its not pure restriction -- more like 100% substitution. Of course, for it to be 100% I have to have a way to disallow direct attaches to '#X'. Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 17:57 -0500, erik quanstrom wrote: And finally, I'd say having these exceptions is a mistake. Unless, there's a really good reason, they break the paradigm of RFNOMNT quite needlessly without even a hint of a benefit. so, it's likely that RFNOMNT was added and to avoid breaking too many things, a few exceptions were added with the intention of fixing and removing them. why don't you submit a patch to rfork(2)? You mean the man page, or the system call? ;-) Thanks, Roman.
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 15:15 -0800, Russ Cox wrote: On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom quans...@quanstro.net wrote: And finally, I'd say having these exceptions is a mistake. Unless, there's a really good reason, they break the paradigm of RFNOMNT quite needlessly without even a hint of a benefit. so, it's likely that RFNOMNT was added and to avoid breaking too many things, a few exceptions were added with the intention of fixing and removing them. i don't see why that's likely. maybe those were simply judged to be the safe set of devices. Ok, here's a practical question: given how little use these exceptions have in existing applications, wouldn't removing them be worth it? Thanks, Roman. P.S. I can submit a patch for kernel and applications alike... ;-)
Re: [9fans] directly opening Plan9 devices
On Sat, 2009-01-03 at 23:21 +0100, Francisco J Ballesteros wrote: Usign #X means doing a mount (you are attaching to the root of the driver's tree). You're right, of course. But it feels like a very special mount if one can refer to files served by the drivers directly through: '#X/bla-bla'. Thanks, Roman. P.S. The whole idea of letting such names be resolved feels like a dreaded parallel namespace(s) madness from POSIX. Something that has always tickled me the wrong way in Plan9.
Re: [9fans] directly opening Plan9 devices
Usign #X means doing a mount (you are attaching to the root of the driver's tree). You're right, of course. But it feels like a very special mount if one can refer to files served by the drivers directly through: '#X/bla-bla'. s/driver/file server/ there doesn't need to be any hardware involved. i don't understand what's special about such a reference. the only difference between this and /somepath/blah-blah is that in the latter case, the referenced element has first become part of the namespace. this is a lot like the difference between a variable and an expression in c. could you explain why you think this is special? - erik
Re: [9fans] directly opening Plan9 devices
could you explain why you think this is special? Perhaps because it is _always_ part of the namespace, where this discussion is specifically about restricting the namespace? Of course, that is how I read it, Roman will need to qualify my view. ++L PS: I also find #X a touch special, but there is really no need to feel that it is an intruder :-) It helps when you point out that it is just a macro for something that cannot be accessed by any legitimate name _before_ a namespace is constructed.
Re: [9fans] directly opening Plan9 devices
On Sun Jan 4 00:01:18 EST 2009, r...@sun.com wrote: On Sat, 2009-01-03 at 17:56 -0500, erik quanstrom wrote: Isn't it too restrictive, eg, not allowing you to create pipes? pipes certianly are an exception. why can the others be bound for you if your jailer sees fit? Why would you call pipes an exception? Is there anything special about them?(*) their implementation uses #| and thus requires an exception to RFNOMNT for pipes to work for jailed processes. i guess i don't see this one as a problem for this case. #| is self-contained and pipes themselves are not named. regardless, it is inconsistent. it might be advantagous to replace the pipe device. perhaps for profiling. replacing devcons and proc seem more interseting. by replacing #p and #c, one could accomplish quite a bit of clustering. i would imagine ron has done this a few times. :-) - erik
Re: [9fans] directly opening Plan9 devices
could you explain why you think this is special? Perhaps because it is _always_ part of the namespace, where this discussion is specifically about restricting the namespace? Of course, that is how I read it, Roman will need to qualify my view. the anticedent special was #X/fu as opposed #X. - erik
Re: [9fans] directly opening Plan9 devices
On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik r...@sun.com wrote: [complaint about # names] No one has yet offered a working, cleaner idea. Russ
