From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Brian L. Stuart" <blstuart@bellsouth.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Wed, 23 Jul 2008 14:40:32 +0000
Message-Id: <072320081440.1316.488742E0000663F50000052422243651029B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net>
In-Reply-To: <20080720075052.9F4D41E8C1F@holo.morphisms.net>
References: <071820082210.18865.488114DC0009E314000049B122193100029B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net>
	<20080720075052.9F4D41E8C1F@holo.morphisms.net>
Subject: Re: [9fans] 9vx and local file systems
Topicbox-Message-UUID: ef86e720-ead3-11e9-9d60-3106f5b1d025

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