On Monday, September 21, 2009, ron minnich rminn...@gmail.com wrote:
If I am in 9vx and have imported a file system from somewhere, and do
an ls, and get impatient and hit del, the import dies.
term% grep full *.c
grep: can't open *.c: '*.c' mount rpc error
term% ls
ls: .: clone failed
this was a direct response to ast many years ago. it was
hard to dig up when i did so in 2006. perhaps someone
has a better link:
- Microkernels are the way to go
False unless your only goal is to get papers published.
Plan 9's kernel is a fraction of the size of any
storage vendors have a credibility problem. i think the big
storage vendors, as referenced in the op, sell you on many
things you don't need for much more than one has to spend.
I went to a product demo from http://www.isilon.com/
They make a filesystem that spans multiple machines. They
On Sep 21, 2009, at 9:33 PM, erik quanstrom wrote:
We're getting bloated and huge. Yes, it's a problem, said
Torvalds.
So may be Tanenbaum was right, after all, there's a reason we make
things modular.
rob, presotto, ken and phil did not agree with tanenbaum's
ideas about modular kernels.
On Mon, Sep 21, 2009 at 9:12 PM, andrey mirtchovski
mirtchov...@gmail.com wrote:
it's on slashdot, it must be true:
During a roundtable discussion at LinuxCon in Portland, Oregon this
afternoon, moderator and Novell distinguished engineer James Bottomley
asked Tovalds whether Linux kernel
- Microkernels are the way to go
False unless your only goal is to get papers published.
Plan 9's kernel is a fraction of the size of any microkernel
we know and offers more functionality and comparable
or often better performance.
not intending to pour
On Mon, Sep 21, 2009 at 7:33 PM, erik quanstrom quans...@quanstro.netwrote:
We're getting bloated and huge. Yes, it's a problem, said Torvalds.
So may be Tanenbaum was right, after all, there's a reason we make
things modular.
rob, presotto, ken and phil did not agree with tanenbaum's
Are these systems more complex to reason about though? Probably :-). But
when you've only got 7 system calls (per the original L4 specifications I've
read over) you don't really have a lot to debug. Just gotta make sure you
chose the correct primitives to compose all the software you need
On Tue, Sep 22, 2009 at 6:48 AM, Eric Van Hensbergen eri...@gmail.comwrote:
On Sep 21, 2009, at 9:33 PM, erik quanstrom wrote:
We're getting bloated and huge. Yes, it's a problem, said Torvalds.
So may be Tanenbaum was right, after all, there's a reason we make
things modular.
rob,
On Tue, Sep 22, 2009 at 7:47 AM, erik quanstrom quans...@quanstro.netwrote:
Are these systems more complex to reason about though? Probably :-).
But
when you've only got 7 system calls (per the original L4 specifications
I've
read over) you don't really have a lot to debug. Just gotta
On Tue Sep 22 11:06:37 EDT 2009, leim...@gmail.com wrote:
The argument is that if something is logically separable from a larger
system, and independently testable, then once you've verified it is correct,
and that the glue is correct that is used to compose a larger system, that
you can more
On Tue, Sep 22, 2009 at 8:14 AM, erik quanstrom quans...@quanstro.netwrote:
On Tue Sep 22 11:06:37 EDT 2009, leim...@gmail.com wrote:
The argument is that if something is logically separable from a larger
system, and independently testable, then once you've verified it is
correct,
and
not intending to pour gas on the flames, but there have been a number of
ukernels since that are a fraction of the size of p9 (and less functional,
by design). Some with very good performance.
i'm not sure what good performance means. is there enough
functionality in current µkernels to even
2009/9/17 Rudolf Sykora rudolf.syk...@gmail.com:
Hello,
is the operator a feature only of native plan 9?
It doesn't seem to work for me in p9p...
Is the right solution then, instead of
program file
write
program file file_tmp
mv file_tmp file
It works fine in p9p, however it
btw, there's even been one ukernel recently that has a formal
proof of correctness (against its specification and some containment
properties). Roughly a 10 man-year effort for about 7.5kloc.
Not something you'd likely be able to do yet against something linux-
sized.
the other way of
OK, a little more fooling around.
term% grep full *.c
(wait about a second, hit DEL)
grep: can't open apic.c: 'apic.c' './sys/src/9/pc/grep' does not exist
grep: can't open apm.c: 'apm.c' mount rpc error
grep: can't open archmp.c: 'archmp.c' mount rpc error
grep: can't open bios32.c: 'bios32.c'
OK, I did this in mntralloc, in the code path in which we reuse the
rpc from the mtnalloc.rpcfree: I just simply always allocated a new
tag, even if we found an old rpc which was nominally free: I always
allocated a new tag, not reusing the old tag.
That fixed the problem.
So, basically, the way
On Tue, Sep 22, 2009 at 10:13 AM, erik quanstrom quans...@quanstro.netwrote:
btw, there's even been one ukernel recently that has a formal
proof of correctness (against its specification and some containment
properties). Roughly a 10 man-year effort for about 7.5kloc.
Not something you'd
2009/9/22 ron minnich rminn...@gmail.com:
So, basically, the way I see it is, grep proc gets an interrupt,
kernel will try to flush RPCs which we initiated, we drop the (we
think) flushed rpc struct onto the rpcfree list, but the reply from
the server is still in flight. We reuse the rpc from
On Tue, Sep 22, 2009 at 11:35 AM, roger peppe rogpe...@gmail.com wrote:
surely the correct way to go about this (caveat: i haven't looked at the code)
is to drop the rpc struct onto the rpcfree list only when the Rflush is
received?
you just got an Eintr. Did the request get sent?
I don't
Hi all
nhc98 uses a few of
static unsigned startLabel[]={};
which is a zero length array. It appears that it uses this as
reference to calculate the correct pointer for a bytecode.
pcc does not allow this since zero lenth array is another gcc
extension. I tried declaring it as
static unsigned
I don't know. I am not sure the code does either. Since this is only
seen so far in 9vx I am guess it is a 9vx thing.
i see this now than then on regular plan 9
Tue Sep 1 18:51:15: unexpected reply tag 51; type 109
Tue Sep 1 18:51:15: unexpected reply tag 16; type 109
Tue Sep 1 18:51:15:
2009/9/22 ron minnich rminn...@gmail.com:
On Tue, Sep 22, 2009 at 11:35 AM, roger peppe rogpe...@gmail.com wrote:
surely the correct way to go about this (caveat: i haven't looked at the
code)
is to drop the rpc struct onto the rpcfree list only when the Rflush is
received?
you just got
if it's ambiguous, then the tag should indeed be put on hold,
because there's no way to get it right.
how do we prevent all tags from being on hold?
there's no way to get that right, either.
- erik
On Sep 22, 2009, at 1:47 PM, ron minnich wrote:
On Tue, Sep 22, 2009 at 11:35 AM, roger peppe rogpe...@gmail.com
wrote:
surely the correct way to go about this (caveat: i haven't looked
at the code)
is to drop the rpc struct onto the rpcfree list only when the
Rflush is
received?
you
On Wed, 23 Sep 2009 02:49:44 +0800 Fernan Bolando fernanbola...@mailc.net
wrote:
Hi all
nhc98 uses a few of
static unsigned startLabel[]={};
which is a zero length array. It appears that it uses this as
reference to calculate the correct pointer for a bytecode.
pcc does not allow
anyone looked at this or given it any thought?
2009/9/22 erik quanstrom quans...@quanstro.net:
if it's ambiguous, then the tag should indeed be put on hold,
because there's no way to get it right.
how do we prevent all tags from being on hold?
there's no way to get that right, either.
well, it's legal to send several flushes for the same
J.R. Mauro writes:
Another thing they won't consider is having separate versions for
high-end servers and PCs. I don't understand why Torvalds thinks Linux
has to be all things to all people.
the Linux running on a high-end server is probably compiled from
the same (evolving over time) source
here is a 9p trace of the problem. See line 43. Topen and Tclunk go
out with same tag. This is with a print in the rpc code as suggested
by Russ.
ron
y
Description: Binary data
here's one last caught in the act scenario. I have a print in
mntralloc when I reuse something.
The fid is being read and clunked. But the Tclunk goes out before the
Rread comes in. Oops.
Reuse 1
Tread tag 1 fid 454 offset 0 count 8192
Reuse 1
Tclunk tag 1 fid 454
reply Rread tag 1 count 8192
On Tue Sep 22 17:22:08 EDT 2009, rminn...@gmail.com wrote:
here's one last caught in the act scenario. I have a print in
mntralloc when I reuse something.
The fid is being read and clunked. But the Tclunk goes out before the
Rread comes in. Oops.
Reuse 1
Tread tag 1 fid 454 offset 0
i'm not clear on what all functional correctness entails. can
a functionally correct program suffer from deadlock or livelock?
Yes. It depends on if that property was stated as part of the
specification of what correctness means.
That is definitely something that can be stated and proven.
I'm
i'm not clear on what all functional correctness entails. can
I thought I'd go into a little more detail about what they did since my
last email probably doesnt clear it up very much. They wrote a model of
their operating system in a high level language (Haskell). They then
translated the
On Sep 22, 2009, at 3:34 PM, Skip Tavakkolian wrote:
anyone looked at this or given it any thought?
I was going to check into it after I did some tests in the audio
system. Although I probably won't finish my tests till early-mid
october.
On Tue, Sep 22, 2009 at 2:23 PM, erik quanstrom quans...@quanstro.net wrote:
On Tue Sep 22 17:22:08 EDT 2009, rminn...@gmail.com wrote:
here's one last caught in the act scenario. I have a print in
mntralloc when I reuse something.
The fid is being read and clunked. But the Tclunk goes out
There were no proofs about the behavior of the C compiler or the underlying
cpu.
In related news, there is a verified Clight compiler out there for
PowerPC machines.
Leroy, X. 2009. Formal verification of a realistic compiler.
Commun. ACM 52, 7 (Jul. 2009), 107-115. DOI=
A very superficial glance a long time ago suggested that it was a
twisty little maze of de-facto and de-vulgus standards.
i.e. the death of a thousand committees.
Then there's the hardware ...
On 22 Sep 2009, at 20:34, Skip Tavakkolian wrote:
anyone looked at this or given it any thought?
On 22/09/2009, at 4:47 PM, Jack Norton wrote:
In the end I don't care what the linux devs do, but they need to
come up with a game plan and either fork (server, desktop linux) or
include it all and try and make everyone happy (the latter will end
in chaos me thinks).
There are several
ron,
this works for me but my symptoms were a little different than yours.
before:
mnt: proc cat 290: mismatch from #D/ssl/1/data /n/coraid/lib/unicode
rep 0x7fcd8c04e190 tag 4 fid 1603 T120 R117 rp 4
after:
WOOT! caught stale reply 6; type 117
note: the poor organization of
full versions in
/n/sources/contrib/quanstro/devmnt.c
/n/sources/contrib/quanstro/vx32devmnt.c
- erik
On Tue Sep 22 23:12:27 EDT 2009, r...@swtch.com wrote:
The extra tracking that has been proposed is unnecessary,
and waiting for the Rflush doesn't make sense. The assumption
is that the Rflush isn't ever going to arrive, because the connection
is dead.
what do you mean by dead? i/o to the
On Tuesday, September 22, 2009, erik quanstrom quans...@quanstro.net wrote:
On Tue Sep 22 23:12:27 EDT 2009, r...@swtch.com wrote:
The extra tracking that has been proposed is unnecessary,
and waiting for the Rflush doesn't make sense. The assumption
is that the Rflush isn't ever going to
I mean that the code as written is assuming that if a read or write
errors out, it can only happen for one of two reasons:
1) there was an interrupt note, in which case strcmp(error, Eintr) == 0
2) there has been an error on the 9P connection, in which case
strcmp(error, Eintr) != 0 and
44 matches
Mail list logo
