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
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.
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?
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
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
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
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
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
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
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
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
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
Things like
term% cd '#|'
term% pwd
#|
just don't seem right.
you ask for fish; you get fish.
what's the trouble?
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
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
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
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
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'.
I agree with Roman. When I open #X/path I feel like back to DOS.
--
Roma
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
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
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] =
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,
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
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
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 =
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
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
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
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
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
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
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
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'.
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
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
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
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
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
39 matches
Mail list logo
