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

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

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.

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

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.

I think this is fixed in hg now. I found one place where
localroot was going to be used even though
it shouldn't.

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.

Yes, that seems to work correctly now.

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

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

I'll give that a try.

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.

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

getting the 404 on that link.

On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart bellsouth.net>
wrote: