The changes I mentioned earlier that allow 9vx to use
a local disk partition as root are ready for advised*
public consumption.
I've put everything up on the page:
http://umdrive.memphis.edu/blstuart/9vx/local9vx.html
Russ, if you want to consider these for inclusion in
the main tree, you can
getting the 404 on that link.
On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart [EMAIL PROTECTED]
wrote:
The changes I mentioned earlier that allow 9vx to use
a local disk partition as root are ready for advised*
public consumption.
I've put everything up on the page:
- boot/boot did bad things if the localroot
wasn't set, so when using boot/boot it's now .
I think this is fixed in hg now. I found one place where
localroot was going to be used even though
it shouldn't.
Yes, that seems to work correctly now.
I'm beginning to think the lock-ups
I'm doing all of this on Linux. Since then, I have seen
it lock up when running from a fossil/venti root and #Z
not bound. I can't support it with statistics, but my gut
reaction is that it's less often though.
If this happens again, then running thread apply all where 20
in gdb should help
- boot/boot did bad things if the localroot
wasn't set, so when using boot/boot it's now .
I think this is fixed in hg now. I found one place where
localroot was going to be used even though
it shouldn't.
I'm beginning to think the lock-ups some of us have
seen are somewhere in
A little while back Russ suggested that someone might
want to look into making 9vx boot using a native
fossil/venti file system partition for root. For
anyone who's interested, as of this morning, that
is working. It's a little kludgy in places, but
mostly it's not too bad. When I've cleaned it
On Fri, 2008-07-18 at 15:00 -0400, erik quanstrom wrote:
my inclination would be to give 9vx a proper
ethernet device, but that idea has been discussed
already.
I was about to ask this very question (and say THANK YOU
to Russ for another awesome piece of software), but now
that you've
my inclination would be to give 9vx a proper
ethernet device, but that idea has been discussed
already.
I was about to ask this very question (and say THANK YOU
to Russ for another awesome piece of software), but now
that you've mentioned it could you, please, elaborate
on why
On Fri, Jul 18, 2008 at 1:20 PM, erik quanstrom [EMAIL PROTECTED] wrote:
but what i'd really like is a drawterm replacement with its own
local devices. without local devices, there isn't much of an
advantage over drawterm — unless your cpu server many
ms away. graphics over the internet can
but what i'd really like is a drawterm replacement with its own
local devices. without local devices, there isn't much of an
advantage over drawterm — unless your cpu server many
ms away. graphics over the internet can be a bummer.
Like I said before, please add the local devices you want.
i just wonder if all the coding around the fact
that the 9vx network is different is going to pay off.
You've spent more time talking about this than
it would have taken to just implement the extra
pieces you want or need, like /net/ipifc and /net/ether.
The low-level OS grunge work is already
why can't venti and fossil on the same machine be connected by a pipe?
why can't venti and fossil on the same machine be connected by a pipe?
why can't venti and fossil on the same machine be connected by a pipe?
That would be far too logical.
Sape
I have used octopus to access my plan 9 system over links
with 150ms of RTT I admit graphics are mostly faces and simple
vector graphics. Considering that for file viewers you copy
the files to a viewer device in the terminal, it all behaves reasonably.
The drawback is that you get very nervous
- boot/boot did bad things if the localroot
wasn't set, so when using boot/boot it's now .
What bad things did it do? The code is supposed
to cope gracefully with localroot == nil. I'd rather
fix the code that couldn't cope.
Ah, that means I need to remember. As you get older,
one of
but what i'd really like is a drawterm replacement with its own
local devices. without local devices, there isn't much of an
advantage over drawterm — unless your cpu server many
ms away. graphics over the internet can be a bummer.
Well, I use vx32 as a terminal for both lguest and
On Fri, Jul 18, 2008 at 6:31 PM, erik quanstrom [EMAIL PROTECTED] wrote:
what's the advantage over drawterm in this configuration?
latency. The interactive program (e.g. acme) is on my machine, not on
a remote machine. Rio is local. And so on.
ron
Well, I use vx32 as a terminal for both lguest and remote machines. No
real need for venfi/fossil. For edit, I import; to build etc. I cpu in
an acme window so i get the error stuff.
what's the advantage over drawterm in this configuration?
In the case you quote, you'd have many of the
19 matches
Mail list logo
