[9fans] 9vx and local file systems - Plan9

This is a discussion on [9fans] 9vx and local file systems - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

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

  1. [9fans] 9vx and local file systems

    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



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

    > 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



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

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



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

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



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

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



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

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



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

    > 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



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

    > 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


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

    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



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

    getting the 404 on that link.

    On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart
    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
    >
    >
    >



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

    the url works fine for me.

    On Thu, Jul 24, 2008 at 9:26 PM, David Leimbach wrote:
    > getting the 404 on that link.
    >
    > On Thu, Jul 24, 2008 at 12:14 PM, Brian L. Stuart
    > 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
    >>
    >>

    >
    >



+ Reply to Thread