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
The let's submit a patch and fix it talk is scary.
i haven't seen any such talk; and in any event,
how can patches be scary?
All the pie-in-the-sky gee it would be nice if it worked
like this, not that I'm actually using it talk is unproductive.
if it helps understand what's there, why it's
I agree that it would be nice if the exceptions were
documented in the man page. They are quite nicely
documented in the code, though:
/*
* noattach is sandboxing.
*
* the OK exceptions are:
* | it only
Constructing a namespace without RFNOMNT that does not have #s (say) bound
is not really securing #s (and its other consumers) against that namespace's
actions. Constructing a namespace with RFNOMNT and without #s bound does
at least two bad things:
- it makes it impossible to pass fds
It's behavior is what it is
because that was necessary to get the job done.
This approach can lead to unexpected side effects. Roman (or was it
Nathaniel?) shows how RFNOMNT may be misunderstood to perform two
functions when in fact there is only one purpose to it. In addition,
only the
Another aspect I noticed is that what you seem to need is a
finer-grained construction of #p and #s, but being able to construct
them one layer further down the hierarchy might suffice.
one layer further down the hierarchy ?
Well, if you could bind a subset of #s by some selection
i haven't even seen what i think is a compelling
argument for sendfd yet you're trying to argue
for second-order problems with a particular
application of sendfd.
Sendfd() seems to me a somewhat more carefully controlled version of
/srv. As it stands, the additional features of sendfd()
I agree that it would be nice if the exceptions were
documented in the man page. They are quite nicely
documented in the code, though:
That's easy enough to do, I'm sure. I'll look into that and see if I
can build the confidence for a patch to, I presume, rfork(2)?
The rationale is also at
On Thu Jan 1 22:02:44 EST 2009, aku...@sounine.nanosouffle.net wrote:
The EXAMPLES section of `man 1 grap' contains an extra paste error: `.G1'
marks the start of a graph description and `.G2' the end -- everything in the
middle has been re-pasted after the `.G2'.
In short:
remove
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
Ah! But I think troff or a preprocessor threw errors at me, for having
that bit (well, it was the only problem I could see, or now remember).
ak
---BeginMessage---
On Thu Jan 1 22:02:44 EST 2009, aku...@sounine.nanosouffle.net wrote:
The EXAMPLES section of `man 1 grap' contains an extra paste
I forgot to put these out earlier; I wrote a bunch of scripts that
should help with the processing of devtrace output. They're what I
used to make the plots in the paper. Just unpack the tarball in your
bin/rc directory and run plots/createplot, hopefully the usage
message should make usage
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'.
On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
The let's submit a patch and fix it talk is scary.
Russ, with all due respect, life gets unnecessarily complicated
when on one hand whenever I suggest something for discussion
there's always a member of this list (you included) who asks
me to
Did you mean to attach the tarball with your mail? Or are we to find
them somewhere else?
ak
E I'm stupid, yeah
The tarball is at /n/sources/contrib/john/devtrace-scripts.tgz
I sometimes forget you people can't read minds :)
John
On Sun, 2009-01-04 at 08:43 +0200, lu...@proxima.alt.za wrote:
Constructing a namespace without RFNOMNT that does not have #s (say) bound
is not really securing #s (and its other consumers) against that namespace's
actions. Constructing a namespace with RFNOMNT and without #s bound does
On Sun, 2009-01-04 at 20:23 +0200, lu...@proxima.alt.za wrote:
i haven't even seen what i think is a compelling
argument for sendfd yet you're trying to argue
for second-order problems with a particular
application of sendfd.
Sendfd() seems to me a somewhat more carefully controlled
two emails, one response
My personal opinion (which seems to be shared by Erik) is that it
is a slippery slope that can be avoided. I haven't seen the
arguments to the contrary so far.
and
The above seems like a net gain, doesn't it?
pretty much, and then not so much.
the current
i understood what Russ said to mean: patches -- for enhancements that
might someday have a use or fixes that remove some perceived
shortcoming lacking an actual need -- are scary.
On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
The let's submit a patch and fix it talk is scary.
Russ, with
i suppose you could accuse me of not wanting to change
anything, but it's hard to be in favor of operating system
feng shui.
I'll go along with Erik that the #-space should not be restricted.
Not because I disagree that it would lead to a cleaner implementation,
but because there is too much
i understood what Russ said to mean: patches -- for enhancements that
might someday have a use or fixes that remove some perceived
shortcoming lacking an actual need -- are scary.
Not if they are first discussed in the type of forum that is savvy to
both the immediate effects and the hidden
On Sat, 2009-01-03 at 18:57 -0500, Nathaniel W Filardo wrote:
That is, if I cannot refer to an object in my namespace and no
server I can refer to will grant access, then I have achieved isolation of
that object and any process running in my namespace.
That sounds like a reasonable
On Sun, 2009-01-04 at 07:03 +0900, sqweek wrote:
On Tue, Dec 30, 2008 at 8:54 AM, Roman Shaposhnik r...@sun.com wrote:
Personally, though, I'd say that the usefulness of the
dump would be greatly improved
if one had an ability to do ad-hoc archival snapshots AND assigning tags,
not only
Well, I guess I really got spoiled by ZFS's ability to do things like
$ zfs snapshot pool/projects/f...@yourtextgoeshere
at the console type snap. if you're allowing snaps to be mounted on
the local fs then the equivalent would be mkdir /YourTextGoesHere;
bind /n/dump/... /
fossil/venti through the lens of ZFS. I guess its not a coincedence
that ZFS actually has a built-in support for the kind of history
transfer you were implementing.
the transfer would have been trivial, had the filesystems been
compatable. what i did was reenact the actions that built the
I apologize for the tone of my first message.
Skip put the words better in his rephrasing.
I was speaking only for myself -- I have no part
in applying patches to Plan 9 anymore. I submit
changes the same as everyone else.
I would hope that any patch changing the behavior
of RFNOMNT would be
I don't believe you can write a race-free implementation of
the pipe system call using #|.
Could you, please, elaborate on what particular race do you have
in mind? Indeed, I ran into a problem with devpipe implementation,
but it isn't a race, its a dreaded implicit -attach that namec()
I agree with Roman. When I open #X/path I feel like back to DOS.
--
Roma
In its current state, /sys/src/cmd/dict/mkindex suicides if
/lib/dict/oed2 is not present and '-d' option is not specified (along
with the dict name) -- fix:
move /sys/src/cmd/dict/mkindex:57 to
after /sys/src/cmd/dict/mkindex:62
(that is, place the Bseek after the conditional on
/sys/src/cmd/dict/dict.c states:
/*
* Assumed index file structure: lines of form
* [^\t]+\t[0-9]+
* First field is key, second is byte offset into dictionary.
* Should be sorted with args -u -t'' +0f -1 +0 -1 +1n -2
*/
whereas, /sys/src/cmd/dict/mkindex outputs:
byte offset key
/sys/src/cmd/dict/dict.c states:
/*
* Assumed index file structure: lines of form
* [^\t]+\t[0-9]+
* First field is key, second is byte offset into dictionary.
* Should be sorted with args -u -t'' +0f -1 +0 -1 +1n -2
*/
whereas, /sys/src/cmd/dict/mkindex outputs:
byte offset key
32 matches
Mail list logo
