9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Brian L. Stuart" <blstuart@bellsouth.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] 9vx and local file systems
Date: Fri, 18 Jul 2008 22:10:36 +0000	[thread overview]
Message-ID: <071820082210.18865.488114DC0009E314000049B122193100029B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net> (raw)
In-Reply-To: <20080718203703.2DEAE1E8C22@holo.morphisms.net>

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




  parent reply	other threads:[~2008-07-18 22:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18 18:22 Brian L. Stuart
2008-07-18 20:39 ` Russ Cox
2008-07-18 20:55   ` Charles Forsyth
2008-07-18 20:50     ` Sape Mullender
2008-07-18 20:55   ` Charles Forsyth
2008-07-18 22:10   ` Brian L. Stuart [this message]
2008-07-20  7:53     ` Russ Cox
2008-07-23 14:40       ` Brian L. Stuart
2008-07-23 17:51         ` Russ Cox
2008-07-23 18:50           ` Brian L. Stuart
2008-07-24 19:14           ` Brian L. Stuart
     [not found]             ` <1cb06bb5ba32c2070a940af01f4d91c3@plan9.bell-labs.com>
2008-07-24 19:24               ` Brian L. Stuart
2008-07-24 19:26             ` David Leimbach
2008-07-24 23:23               ` Francisco J Ballesteros
     [not found] <071820081822.3544.4880DF75000734D900000DD822218675169B0A02D2089B>
2008-07-18 19:00 ` erik quanstrom
2008-07-18 19:50   ` Roman V. Shaposhnik
2008-07-18 20:20     ` erik quanstrom
2008-07-18 20:28       ` ron minnich
2008-07-19  1:31         ` erik quanstrom
2008-07-19  2:10           ` ron minnich
2008-07-19  2:37           ` Russ Cox
2008-07-18 20:31       ` Russ Cox
2008-07-18 21:55       ` Francisco J Ballesteros
2008-07-18 20:35   ` Russ Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=071820082210.18865.488114DC0009E314000049B122193100029B0A02D2089B9A019C04040A0DBF9B9D0E9A9B9C040D@att.net \
    --to=blstuart@bellsouth.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).