/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:
i.e.,
0 ヽ
/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:
i.e.,
0 ヽ
> The # device syntax is very useful to mean the kernel device
> and none other in these situations. There's definitely
> something unsatisfactory about it, but it works.
Smacks of overloading; at the very least it seems to suggest that
there ought to be official sanction as well as documented si
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 Bo
I agree with Roman. When I open #X/path I feel like back to DOS.
--
Roma
>> 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 name
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 base
> 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
o
> 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/... / /YourTextGoes
> Well, I guess I really got spoiled by ZFS's ability to do things like
> $ zfs snapshot pool/projects/f...@yourtextgoeshere
> and especially:
> $ zfs clone pool/projects/f...@yourtextgoeshere pool/projects/branch
>
> I'm still trying to figure out what kind of approximation of the above
>
On Mon, 2008-12-29 at 19:57 -0500, erik quanstrom wrote:
> history is not a property of venti. venti is a sparse virtual drive
> with ~2^80 bits storage. blocks are addressed by sha1 hash of
> their content. fossil is the fileserver. the analogy would be a change
> in fossil format. my techniqu
On Sun, 2009-01-04 at 07:03 +0900, sqweek wrote:
> On Tue, Dec 30, 2008 at 8:54 AM, Roman Shaposhnik 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 dates
On Sat, 2009-01-03 at 22:56 -0800, Russ Cox wrote:
> On Sat, Jan 3, 2009 at 9:04 PM, Roman V. Shaposhnik wrote:
> > I'm confused. Is there any part of syspipe() that can NOT
> > be done from userspace? Why does it have to be a syscall?
> >
> > P.S. I would also argue that sysdup() would seem to be
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 expectati
> 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 hidde
> 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.
> On Sat, 2009-01-03 at 23:08 -0800, Russ Cox wrote:
>> The "let's submit a patch and fix it" talk is scary.
>
> Ru
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 curr
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 con
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 doe
> 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 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
--- Begin Message ---
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 unpa
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:
> >
On Sat, 2009-01-03 at 23:01 -0800, Russ Cox wrote:
> On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik 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 invitati
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 cle
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
--- Begin Message ---
On Thu Jan 1 22:02:44 EST 2009, aku...@sounine.nanosouffle.net wrote:
> The EXAMPLES section of `man 1 grap' contains an "extra pa
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:
>
> 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 a
> 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()
> 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 fd
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 gi
> 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
> >> 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
> 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 k
As I read it, rob seems to disagree with you:
> # 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.
>
> # was never considered a great idea; I just needed some way to
name an unnamed resource. I deliberately
> 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 orig
> 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
38 matches
Mail list logo
