>> I just hacked in support for booting with -r, which prompts for a
>> root directory to run under at boot time.  It passes a smoke test,
>> but needs real testing.  (I'm also going to add -i, to make it
>> prompt for a path to use for init [...].)

[one reply says]
> Nice.  Sun uses the -i flag for this already; I think -r is reserved
> under Slowlaris, but that's moot :-).  Good ideas!

[another reply says]
> Why not go the Solaris way and implement "-a" which asks you at a set
> of prompts where to find /, init (and anything else) rather than
> command line options (CLO) for each ?

Well, we already have -a, which causes a whole bunch of things to get
prompted for, starting with the bootloader prompting for the boot
device.  Yes, it probably would make some sense to conditionalize these
on RB_ASKME rather than new bits set by new options, and I may do it
that way.

But there's something more serious: -r as I've implemented it can't
work.  (-i is implemented and works very nicely.)

What I did for -r is, in main() [kern/init_main.c], after setting up
the root filesystem mount, prompt for a path, and use the vnode it
references as rootvnode (and the cdir for processes 0, 1, 2).

The problem is, / is mounted read-only.  To remount it read-write,
userland does "mount -o update /dev/whatever /".  This doesn't work,
because when the kernel looks up / to get the mounted-on vnode, it gets
a different vnode from the one the root device is currently mounted on.
I'm thinking about possible ways to fix this, but so far all I have is
ideas.  (The one I currently favor is to remember the *real* root and
have mount(2) silently substitute that when userland tries to mount
onto rootvnode.  Note this doesn't affect how mount(2) interacts with
chroot(2), because I'm talking about rootvnode, not fd_rdir.)

> I suspect using one CLO for all of this class of option is a tad
> better than one for each given that such events are nearly always
> attended anyway.

Well...in some respects.  It has problems, though; notably that the
kernel sometimes sets RB_ASKNAME internally (for example, if it can't
mount what it thinks root is supposed to be, it sets RB_ASKNAME to
cause a prompt for a new place to find root).  It would be unpleasant
and somewhat counterintuitive for this to suddenly turn on all this
prompting for alternative root and init path and such.

It *would* be possible to have -a turn on multiple RB_ flags, and that
may be better than what I currently have.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B