[9fans] 9vx is really excellent, link it on the bell-labs pages?

[9fans] 9vx is really excellent, link it on the bell-labs pages?

[Sam Watkins]

I just installed 9vx under Linux on my eee pc, it's a delight to be able to run
2 or 3 instances of plan 9 with no bother under Linux!  I can't really run Plan
9 as my main OS at the moment, but it seems there's not a big performance hit
to run it in 9vx.

I want to say "thanks!" to Russ for packaging this up (and to the plan 9 devs
of course), and I want to suggest that there should be a link to 9vx on the
main plan 9 website.  I suppose most of the people who are interested in Plan 9
would be Unix / Linux users like me, it's a very good way to try or use it for
those people.

Sam

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

I think it's officially a port of Plan 9's kernel to the vx32 stuff, so it's
not precisely the same as running a Plan 9 box natively, or in another
emulator, but it is indeed quite a feat, and "close enough" that most people
won't notice.
Personally, I'd love to be able to completely replace drawterm with 9vx, but
for some reason I still have a little trouble with that setup (in fact I've
not finished setting up my CPUFSAUTH server yet, so really I'm the reason
for that).

Another interesting project would be an Inferno based drawterm :-)... but
I'd be lying if I said I had any time for that kind of fun.

Dave

On Wed, Sep 30, 2009 at 1:23 AM, Sam Watkins <sam@nipl.net> wrote:

> I just installed 9vx under Linux on my eee pc, it's a delight to be able to
> run
> 2 or 3 instances of plan 9 with no bother under Linux!  I can't really run
> Plan
> 9 as my main OS at the moment, but it seems there's not a big performance
> hit
> to run it in 9vx.
>
> I want to say "thanks!" to Russ for packaging this up (and to the plan 9
> devs
> of course), and I want to suggest that there should be a link to 9vx on the
> main plan 9 website.  I suppose most of the people who are interested in
> Plan 9
> would be Unix / Linux users like me, it's a very good way to try or use it
> for
> those people.
>
> Sam
>
>

[-- Attachment #2: Type: text/html, Size: 1742 bytes --]

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[Ethan Grammatikidis]

On Wed, 30 Sep 2009 07:45:17 -0700
David Leimbach <leimy2k@gmail.com> wrote:

> I think it's officially a port of Plan 9's kernel to the vx32 stuff, so it's
> not precisely the same as running a Plan 9 box natively, or in another
> emulator, but it is indeed quite a feat, and "close enough" that most people
> won't notice.
> Personally, I'd love to be able to completely replace drawterm with 9vx, but
> for some reason I still have a little trouble with that setup (in fact I've
> not finished setting up my CPUFSAUTH server yet, so really I'm the reason
> for that).

Running 9vx instances as Plan 9 terminals fits better with the Plan 9
way than running Drawterm, aye.  :) I'd like to but I use Rio's hold
feature for making quick notes all the time, notes which I need to
have around for a few days.  I don't think I'll be using 9vx for
terminal work until at least 6 months after I hear the last word about
it crashing.

Now 9vx for CPU work; that's another matter.  That could very well
work better for me than my present QEmu-based CPU server, perhaps with
a QEmu-based file server.  OTOH I'd still need a QEmu-based terminal
server sort of wierd thing to use with drawterm, which leaves me
pondering the port assignments if not the overall logic of the
setup....  Hmm!  :)

Anyway, I think 9vx is a great thing too, despite the occasional
crash.  As someone posted a week or two ago it even works well for
testing many kernel changes, having minimal boot-up time.  As to
changing the Plan 9 homepage, that may be a difficult matter.  The
wiki seems largely kept up to date, but the homepage and recommended
reading not so much.

>
> Another interesting project would be an Inferno based drawterm :-)... but
> I'd be lying if I said I had any time for that kind of fun.

--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[matt]

I've had "/bin/rc: not found" twice from Qemu with clean shutdowns

I run it in with -snapshot now and do manual commits (or rather, I did
before I went to back to dedicated hardware)

My drawterm also pops out of existence sometimes when I'm using Acme.
If I restart it and open the same file, the same thing happens.
If I open a difference file for a while and go back it works fine.

I can't fathom how to reproduce it so I've never reported it and hope it
is somehow Linux' fault. It also crashes with an assert in X11 code one
in ten times at startup [but not when you do while() drawterm ... &&
sleep 1] (tip don't do that if you like your X session as I just found
out !)


>On Wed, 30 Sep 2009 07:45:17 -0700
>David Leimbach <leimy2k@gmail.com> wrote:
>
>
>
>>I think it's officially a port of Plan 9's kernel to the vx32 stuff, so it's
>>not precisely the same as running a Plan 9 box natively, or in another
>>emulator, but it is indeed quite a feat, and "close enough" that most people
>>won't notice.
>>Personally, I'd love to be able to completely replace drawterm with 9vx, but
>>for some reason I still have a little trouble with that setup (in fact I've
>>not finished setting up my CPUFSAUTH server yet, so really I'm the reason
>>for that).
>>
>>
>
>Running 9vx instances as Plan 9 terminals fits better with the Plan 9
>way than running Drawterm, aye.  :) I'd like to but I use Rio's hold
>feature for making quick notes all the time, notes which I need to
>have around for a few days.  I don't think I'll be using 9vx for
>terminal work until at least 6 months after I hear the last word about
>it crashing.
>
>Now 9vx for CPU work; that's another matter.  That could very well
>work better for me than my present QEmu-based CPU server, perhaps with
>a QEmu-based file server.  OTOH I'd still need a QEmu-based terminal
>server sort of wierd thing to use with drawterm, which leaves me
>pondering the port assignments if not the overall logic of the
>setup....  Hmm!  :)
>
>Anyway, I think 9vx is a great thing too, despite the occasional
>crash.  As someone posted a week or two ago it even works well for
>testing many kernel changes, having minimal boot-up time.  As to
>changing the Plan 9 homepage, that may be a difficult matter.  The
>wiki seems largely kept up to date, but the homepage and recommended
>reading not so much.
>
>
>
>>Another interesting project would be an Inferno based drawterm :-)... but
>>I'd be lying if I said I had any time for that kind of fun.
>>
>>
>
>
>

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[matt]

> I've had "/bin/rc: not found" twice from Qemu with clean shutdowns

I've also *just* had the disk go bad during the install to a qcow2 disk,
at 90%+ too :(

(or at least I think it went bad, I had lots of /n/newfs not found based
errors)

I started over with a raw disk instead

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[ron minnich]

I think we owe the vx32/9vx guys some help here.

So here's the question. 9vx is running. It breaks. How should we go
about providing
- useful diagnosis
- useful backtracking

There are some tools. Worst case, those of us who see it die from time
to time could elect to run it under gdb for a while. No real pain
there, and we could get some gain. For real pain but possible gain, we
could run it under a function tracer.

Even better, somebody using these tools might have a bright idea for
debugging programs using vx32 or under 9vx and improve the process.

Now I have to confess I can't recall how to print all the thread
callback stacks when 9vx breaks, not having had to do it for a year or
so but ... I'm happy to set up a gdb for it and do what commands are
needed should it break. Any recommendations here Russ?

I see 9vx as a great tool, but, also, a great way for people to start
mucking with the plan 9 kernel and learning. It's a great deal more
approachable than Linux. And with 9vx there's no hardware required.

One other question -- anybody know how to create a 'tracking fork' in
mercurial such that I can fork 9vx, but update from Russ's version to
mine over time? I have some things I want to try out. I have not found
a way to do this  yet. The reason to do this "private repo" would be
to have some other place to store my experiments than my laptop ...

thanks

ron

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[Russ Cox]

> Now I have to confess I can't recall how to print all the thread
> callback stacks when 9vx breaks, not having had to do it for a year or
> so but ... I'm happy to set up a gdb for it and do what commands are
> needed should it break. Any recommendations here Russ?

thread apply all where
is the gdb command to get all stack traces.

> One other question -- anybody know how to create a 'tracking fork' in
> mercurial such that I can fork 9vx, but update from Russ's version to
> mine over time? I have some things I want to try out. I have not found
> a way to do this  yet. The reason to do this "private repo" would be
> to have some other place to store my experiments than my laptop ...

Every checkout in Mercurial is a fork like that.
The easiest setup is to pick one such checkout
to be your coordination point.

    hg clone http://code.swtch.com/vx32/ vx32-main

Then you can clone vx32-main and push to
and pull from it.  When you want to update you
go into vx32-main and run hg pull, merge, and
then re-pull from your various clones.

If you are on another machine from where vx32-main
is, you can clone it with

    hg clone ssh://kremvax//home/rminnich/vx32-main

Russ

Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?

[Ethan Grammatikidis]

On Wed, 30 Sep 2009 17:54:52 +0100
matt <maht-9fans@maht0x0r.net> wrote:

>
> > I've had "/bin/rc: not found" twice from Qemu with clean shutdowns
>
> I've also *just* had the disk go bad during the install to a qcow2 disk,
> at 90%+ too :(
>
> (or at least I think it went bad, I had lots of /n/newfs not found based
> errors)
>
> I started over with a raw disk instead
>

Owwwww!  You know one thing..  I've had trouble getting qemu to build
in the past and ended up using qemu 0.9.1 long after 1.0 was out, and
it's rock solid.  I've had no trouble from qemu at all.  I think I'll
stick with 0.9.1 now!  Oh btw the man pages for 0.9.1 seemed to imply
that qcow2 was really only to be used where the host OS doesn't
support holes.  (Holes are long runs of 0, and can be stored as a
simple length.) Maybe it's not tested very well any more.

As to drawterm, I've held xorg-server back too.  It's at 1.4.2, and
I'm having no trouble with drawterm.  I really hate the careless
changes in recent xorg-server versions, several old-but-good functions
don't work right any more.

--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.