Subject: Re: /kern/kernel
To: None <firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 09/14/1998 08:23:55
>> 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
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.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B