Re: [9fans] 9vx and local file systems

Re: [9fans] 9vx and local file systems

[erik quanstrom]

> - The messiest bit, though, is venti and networking.
> boot/boot figures it needs to set up the loopback
> interface for venti.  But /net/ipifc doesn't exit
> and boot/boot considers this fatal.  I suppose
> the Right Way(tm) to is to implement /net/ipifc
> and have it translate operations to the underlying
> network stack, but that seems an awful lot of
> work, for rather few applications.  The not so
> right way would be to fake it, providing the
> interface, but just pretend all the messages
> succeed.  But I copped out.  I made one change
> to boot/boot.  Now if it fails to open /net/ipifc/clone,
> it's not fatal.

the fact that the networking works differently is
a problem for a number of other applications, too.
dns, snoopy, aoe, cec come immediately to mind
as useful stuff that won't work with 9vx.

my inclination would be to give 9vx a proper
ethernet device, but that idea has been discussed
already.

i just wonder if all the coding around the fact
that the 9vx network is different is going to pay off.

- erik

Re: [9fans] 9vx and local file systems

[Roman V. Shaposhnik]

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 mentioned it could you, please, elaborate
on why implementing proper ethernet was rejected?

Thanks,
Roman.

P.S. Either that or just a pointer to the existing
discussion ;-)

Re: [9fans] 9vx and local file systems

[erik quanstrom]

>> 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 implementing proper ethernet was rejected?

http://9fans.net/archive/2008/07/310

to paraphrase with my understanding, the feeling is that
9vx will be easier to admin if the host takes care of the
networking, dns, etc.  that makes sense for many applications.

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.

- erik

Re: [9fans] 9vx and local file systems

[ron minnich]

On Fri, Jul 18, 2008 at 1:20 PM, erik quanstrom <quanstro@coraid.com> 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 be a bummer.
>

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.

don't really want fossil/venti on vx32 yet, too slow (I tried it some
time last week). But it's a great terminal, much nicer than drawterm
for me.

ron

Re: [9fans] 9vx and local file systems

[Russ Cox]

> 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.
Just don't make them mandatory.

Russ

Re: [9fans] 9vx and local file systems

[Russ Cox]

> 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 done thanks
to p9p.  It's just a few lines of code.

Or, if you are so inclined, you can port the entire
existing Plan 9 IP stack.  That's more than just a
few lines of code.

Either way, complaining isn't nearly as effective as doing.

Russ

Re: [9fans] 9vx and local file systems

[Francisco J Ballesteros]

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 regarding losing your
system due to power outages at the university :)

> advantage over drawterm — unless your cpu server many
> ms away.  graphics over the internet can be a bummer.
>
> - erik
>
>
>

Re: [9fans] 9vx and local file systems

[erik quanstrom]

>> 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 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?

- erik

Re: [9fans] 9vx and local file systems

[ron minnich]

On Fri, Jul 18, 2008 at 6:31 PM, erik quanstrom <quanstro@quanstro.net> 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

Re: [9fans] 9vx and local file systems

[Russ Cox]

>> 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 advantages
of a standalone Plan 9 terminal, like local handling of graphics
and the mouse, the ability to connect to many machines
simultaneously, the ability to withstand those machines
rebooting, and so on.  It depends a lot on what you're doing.

Here's another example.

For about seven years I had the luxury of running Plan 9
as my day-to-day system, but I couldn't easily keep doing
that and work with the people around me at MIT; around
2003, I gave it up and switched to FreeBSD and Linux.
(You'll note that's when the p9p CVS logs begin.)
I haven't booted an actual Plan 9 terminal in a couple of years.

Since then, I've had the smaller luxury of running Plan 9
as a venti server, now atop some nice hardware we bought
from Coraid.  The Coraid box has a tiny, slow IDE flash disk
for a root file system, fine for holding a few binaries but
not really usable as a general file system.  To build the binaries,
I have a second Plan 9 server with a bigger, faster root disk.
I've used drawterm to connect to it, edit and compile venti,
and submit patches.  As I look forward to finishing at MIT,
I can't leave Plan 9 boxes for others to deal with.  A few months
ago, I converted the main venti server (the Coraid hw) to run
FreeBSD, which is what all our other servers run.  That leaves
the second Plan 9 server, which I still use for the occasional
drawterm session to submit a patch to sources.  But when I
leave MIT, I can't reasonably keep using that machine as my
own personal server.  It'll have to be a group server running
FreeBSD.

The advantage of 9vx over drawterm, for me, is that 9vx
doesn't require a cpu server.

9vx is how I'm going to deal with not having my own
personal Plan 9 cpu server to drawterm into.  Having a local
Plan 9 install, stored right in my non-Plan 9 home directory,
lets me keep using and occasionally contributing to Plan 9
without having to maintain and house a server.
I haven't spent quite enough time setting up a comfortable
9vx that I could stop using drawterm today, but maybe
tomorrow.

Russ

[9fans] (no subject)

[kokamoto]

> The advantage of 9vx over drawterm, for me, is that 9vx
> doesn't require a cpu server.

You are not using Plan 9 anymore then, rather you are using something
similar to Plan 9.

I felt that Plan 9 is abused by 9vx, which I felt at first glance, but
at that time I didn't want to say this...

I prefer drawterm because it stands in the Plan 9 world.

Kenji   --just my opinion--

Re: [9fans] (no subject)

[a]

// You are not using Plan 9 anymore then, rather you are
// using something similar to Plan 9.

I don't think it's that simple. I understand the value of running a
native Plan 9 installation (self-sufficiency is an almost universal
value), but we don't hear the same complaints when we look at
Inferno: stuff built from /emu is just as much "real" Inferno as
stuff built from /os. We don't think of using the other hardware
virtualizers as not being "real" Plan 9, even the ones that take
kernel modifications.

9vx just feels like cheating because it's so much easier.

Anthony

Re: [9fans] 9vx vs drawterm

[Tim Wiess]

>> The advantage of 9vx over drawterm, for me, is that 9vx
>> doesn't require a cpu server.
>
> You are not using Plan 9 anymore then, rather you are using something
> similar to Plan 9.
>
> I felt that Plan 9 is abused by 9vx, which I felt at first glance, but
> at that time I didn't want to say this...
>
> I prefer drawterm because it stands in the Plan 9 world.

While I haven't yet gotten the chance to play with it, personally I
felt 9vx is really a normal P9 terminal, whereas drawterm is not.
Because it doesn't run natively makes no difference.

[9fans] Sam

[Benjamin Huntsman]

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

the 9pm version is still the latest Sam for Windows, right?

Thanks!

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2120 bytes --]

Re: [9fans] 9vx and local file systems

[Francisco J Ballesteros]

the url works fine for me.

On Thu, Jul 24, 2008 at 9:26 PM, David Leimbach <leimy2k@gmail.com> wrote:
> getting the 404 on that link.
>
> On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart <blstuart@bellsouth.net>
> 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:
>>
>> http://umdrive.memphis.edu/blstuart/9vx/local9vx.html
>>
>> Russ, if you want to consider these for inclusion in
>> the main tree, you can pull it from there, or I can
>> send them to you in another form if that's preferable.
>>
>> * May cause cancer in rats.  Your mileage may vary.
>> Some side effects are dry mouth, drowsiness, and
>> trouble sleeping.  Ask your doctor if this may be
>> right for you.
>>
>> Thanks,
>> BLS
>>
>>
>
>

Re: [9fans] 9vx and local file systems

[David Leimbach]

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

getting the 404 on that link.

On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart <blstuart@bellsouth.net>
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:
>
> http://umdrive.memphis.edu/blstuart/9vx/local9vx.html
>
> Russ, if you want to consider these for inclusion in
> the main tree, you can pull it from there, or I can
> send them to you in another form if that's preferable.
>
> * May cause cancer in rats.  Your mileage may vary.
> Some side effects are dry mouth, drowsiness, and
> trouble sleeping.  Ask your doctor if this may be
> right for you.
>
> Thanks,
> BLS
>
>
>

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

Re: [9fans] 9vx and local file systems

[Brian L. Stuart]

Geoff has pointed out to me that I made a mistake in
typing the URL in my last message.  It should be:

http://umdrive.memphis.edu/blstuart/htdocs/9vx/local9vx.html

I left the htdocs out of it the first time.  Sorry
for any confusion.

BLS

Re: [9fans] 9vx and local file systems

[Brian L. Stuart]

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 pull it from there, or I can
send them to you in another form if that's preferable.

* May cause cancer in rats.  Your mileage may vary.
Some side effects are dry mouth, drowsiness, and
trouble sleeping.  Ask your doctor if this may be
right for you.

Thanks,
BLS

Re: [9fans] 9vx and local file systems

[Brian L. Stuart]

> If this happens again, then running "thread apply all where 20"
> in gdb should help determine what's going on.

I'll give that a try.

> I would be inclined to do away with full plan9.ini
> parsing and just read a file containing 
> 
> 	name=value
> 
> lines that get stuffed immediately into the config 
> environment (ksetenv).

As it turns out, that's more or less what I've done.
I don't build an internal structure or try to leave
it in some known place in memory like the original,
and I dumped the bits that parse the device type and
stuff.  All that's left is calling ksetenv() on everything
I find.

So most of the device related stuff just gets ignored.
But things like nobootprompt, venti, fs, auth, user,
etc can all be useful.  I did keep the menu handling
since it was little work to keep it and because I think
it can be useful.  At least I plan to use it to let
me select between connecting to an external file server
and using a local fossil/venti.

BLS

Re: [9fans] 9vx and local file systems

[Russ Cox]

> 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 determine what's going on.

> 9vx read a plan9.ini file.  So I've been folding 9load's
> ini file reader into 9vx.  This is not so much massaging
> as with part.c, but liposuction.

I would be inclined to do away with full plan9.ini
parsing and just read a file containing

	name=value

lines that get stuffed immediately into the config
environment (ksetenv).  Or just pass a couple
name=value pairs on the command line.

Allowing the plan9.ini disease to spread seems
like a lose.

Russ

Re: [9fans] 9vx and local file systems

[Brian L. Stuart]

> >> > - 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 some of us have
> > seen are somewhere in devfs-posix.c.  When I'm using
> > it like drawterm, I've never seen it lock up.  When
> > I was using it with the local fossil/venti as root
> > today, it didn't.  In neither case was #Z bound.
> > It's at least suggestive.
>
> Since the local fossil/venti goes through #Z to get at
> the disk device, this doesn't exactly support your theory.
> I can still believe it, though.  Are you perhaps on a Mac?
> I fixed some pthread-related bugs on July 3 in hg,
> which is post-0.12.

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.

> > I had been trying not to modify anything outside of
> > vx32/src/9vx.  In particular, I liked the idea that
> > all Plan 9 executables would work unmodified.
>
> I agree, but /boot/boot is not an ordinary Plan 9
> executable.  It's hard-coded into the running kernel
> (or 9vx) and is always kernel-specific (each kernel
> config typically builds a different one with slightly
> different parameters), so it's fine if you need to build
> a slightly different /boot/boot for 9vx too.

Fair point.  The one change I did make should still work
fine on other kernels.  In that case, if configuring loopback
fails, then boot won't crash, but fossil will complain that
it can't get to venti.

The last couple days I've been looking at something else
that had slipped my mind in my earlier mail.  boot/boot
expects the venti environment variable to be set.  Normally,
this is done by 9load (as with the partitioning).  When
I got it working, I had hard-coded it in main.c and forgot
about it.  I spent most of a day trying to figure out how
to modify boot/boot so that it would behave without $venti
and would do the right thing in all cases, and then it hit
me that I was attacking the wrong problem.  I could take
care of this and open up other possibilities by having
9vx read a plan9.ini file.  So I've been folding 9load's
ini file reader into 9vx.  This is not so much massaging
as with part.c, but liposuction.

Hopefully, I'll have some cleaned up patches available soon.

BLS

Re: [9fans] 9vx and local file systems

[Russ Cox]

>> > - 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 devfs-posix.c.  When I'm using
> it like drawterm, I've never seen it lock up.  When
> I was using it with the local fossil/venti as root
> today, it didn't.  In neither case was #Z bound.
> It's at least suggestive.

Since the local fossil/venti goes through #Z to get at
the disk device, this doesn't exactly support your theory.
I can still believe it, though.  Are you perhaps on a Mac?
I fixed some pthread-related bugs on July 3 in hg,
which is post-0.12.

>> >  But I copped out.  I made one change
>> > to boot/boot.  Now if it fails to open /net/ipifc/clone,
>> > it's not fatal.
>>
>> I think this is a fine solution for this particular case.
>
> I had been trying not to modify anything outside of
> vx32/src/9vx.  In particular, I liked the idea that
> all Plan 9 executables would work unmodified.

I agree, but /boot/boot is not an ordinary Plan 9
executable.  It's hard-coded into the running kernel
(or 9vx) and is always kernel-specific (each kernel
config typically builds a different one with slightly
different parameters), so it's fine if you need to build
a slightly different /boot/boot for 9vx too.

Russ

Re: [9fans] 9vx and local file systems

[Brian L. Stuart]

> > - 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 the first things to go is the ability to form
new memories.  What were we talking about?

Seriously, that was one of the ones that went by
pretty quickly.  Several had the basic behavior
of boot/boot exiting because it found something
that made it call fatal().  Then when it died,
9vx happily rolled over and played dead.  When
the window first vanished, it was a bit startling.

In this particular case, I had to just recreate it
to remind myself.  When boot/boot tries to see if
#S/sd00/fossil exists, it can't find it and decides
it can't connect that way.  The more I look at it
now, the less I understand it.  It seems to be that
I'm not finding my drives.  When I search for available
drives, I construct names like #Z/dev/sda.  So it
does go through devfs-posix, and that's the only place
localroot is really used.  But at first glance, at
least, it looks like that path name shouldn't be
hitting the uses of localroot. Anyway, that's the
symptom, and setting localroot to pretty much anything
makes it work.

While I'm thinking about it, there are couple of
other interesting things I had forgotten earlier.
Because we don't have /dev/rtc (yet), boot/boot
ends up asking for the date and time twice.

I'm beginning to think the lock-ups some of us have
seen are somewhere in devfs-posix.c.  When I'm using
it like drawterm, I've never seen it lock up.  When
I was using it with the local fossil/venti as root
today, it didn't.  In neither case was #Z bound.
It's at least suggestive.

> >  But I copped out.  I made one change
> > to boot/boot.  Now if it fails to open /net/ipifc/clone,
> > it's not fatal.
>
> I think this is a fine solution for this particular case.

I had been trying not to modify anything outside of
vx32/src/9vx.  In particular, I liked the idea that
all Plan 9 executables would work unmodified.

BLS

Re: [9fans] 9vx and local file systems

[Charles Forsyth]

why can't venti and fossil on the same machine be connected by a pipe?

Re: [9fans] 9vx and local file systems

[Charles Forsyth]

why can't venti and fossil on the same machine be connected by a pipe?

Re: [9fans] 9vx and local file systems

[Sape Mullender]

> why can't venti and fossil on the same machine be connected by a pipe?

That would be far too logical.

	Sape

Re: [9fans] 9vx and local file systems

[Russ Cox]

> 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 up
> a bit I'll make some patches available.

Thanks for working through this.
I'm glad to hear it works.

> - 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.

> - The messiest bit, though, is venti and networking.
> boot/boot figures it needs to set up the loopback
> interface for venti.  But /net/ipifc doesn't exit
> and boot/boot considers this fatal.  I suppose
> the Right Way(tm) to is to implement /net/ipifc
> and have it translate operations to the underlying
> network stack, but that seems an awful lot of
> work, for rather few applications.  The not so
> right way would be to fake it, providing the
> interface, but just pretend all the messages
> succeed.  But I copped out.  I made one change
> to boot/boot.  Now if it fails to open /net/ipifc/clone,
> it's not fatal.

I think this is a fine solution for this particular case.

I would like to have a /net/ipifc that showed info
about the host IP interfaces, and then /boot/boot
could check whether there is already a loopback
before adding one, but that's certainly not necessary.

Russ

[9fans] 9vx and local file systems

[Brian L. Stuart]

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 up
a bit I'll make some patches available.

If you care about the gory details:
- Putting fossil and venti in the 9vx image was the
easy part.
- Making sdloop identify the available disks on
startup wasn't too bad.  I couldn't think of a
better way to search than to look for the common
naming schemes: sd[a-j0-9], hd[a-j], wd[0-9],
cciss/c[0-8]d[0-8].  The only gotcha was that
this happened too early for namec() to work, so
I deferred namec() until the first attempt to use
the device.
- boot/boot did bad things if the localroot
wasn't set, so when using boot/boot it's now .
- The kernel normally gets the partitioning for
the root drive from 9load, but we don't have
9load here.  So I stole part.c from /sys/src/boot
and "adjusted" it and devsd.c to play nice
together.
- The messiest bit, though, is venti and networking.
boot/boot figures it needs to set up the loopback
interface for venti.  But /net/ipifc doesn't exit
and boot/boot considers this fatal.  I suppose
the Right Way(tm) to is to implement /net/ipifc
and have it translate operations to the underlying
network stack, but that seems an awful lot of
work, for rather few applications.  The not so
right way would be to fake it, providing the
interface, but just pretend all the messages
succeed.  But I copped out.  I made one change
to boot/boot.  Now if it fails to open /net/ipifc/clone,
it's not fatal.

Thanks,
BLS