re: CVS commit: src/sys/dev/raidframe

[matthew green <mrg%eterna.com.au@localhost>]

> | > Log Message:
> | > If we are autoconfiguring root, then only change the booted_device if
> | > we booted from one of the components of the root raid set. This allows
> | > us to boot from other media, without forcing the found raid to always
> | > be root. Allow the old behavior with RAIDFRAME_FORCE_ROOT.
> | > XXX: cpu_rootconf() is called twice now, which prints the booted device
> | > message twice. Perhaps we can remember that cpu_rootconf has been called
> | > and avoid calling it twice to avoid that.
> | 
> | i like this.. i think.
> | 
> | i wonder if this will break my system that boot from a different
> | device to the raid root device.
> 
> I think it will.
> 
> | eg, ultra10 whose prom can't talk to my sata disk, and boots from
> | a cf/ide fob with just ofwboot and netbsd (and attaches as wd0),
> | and mountroots from the raidframe on wd1+wd2.
> 
> Well, there are different options here:
> 1. is there a way to pass the root from ofwboot to netbsd?
> 2. since netbsd knows it boots normally from raid, you can put a 
>       "root on raidx" statement in your kernel.
> 3. you can compile the kernel with RAIDCTL_FORCE_ROOT
> 4. we can add an option to mark the raid as force root.

kernel configuration changes are not solutions, so 2 and 3 are out.  

if we do 4, we should instead add an option to mark something as a
'soft root', and leave the current semantics alone.  the machines i
have that are now not going to reboot properly are both used
remotely, so changing semantics about how they work seems like a
bad idea.  i'm pretty sure i'm not the only one who does this.
i think i like this the best.

ofwboot doesn't know about the real root -- it can't talk to those
disks at all, because it can't talk to the sata controller they're
attached to, so i'm not sure how to do 1.


.mrg.