In article <20061011204302.GA4426@NetBSD.org>,
Emmanuel Dreyfus  <manu@netbsd.org> wrote:
>-=-=-=-=-=-
>
>The situation: I have a machine with multiple RAID sets, several sets are
>configured as root capables.
>
>That causes rf_buildroothack() to set RB_ASKNAME so that the admin can 
>decide which root should be used.
>
>IMO this is a wrong behavior, as this will cause setroot() to ignore
>a root specification hardcoded in the kernel config file: if I build
>a kernel with "root at raid0a type ffs dumps on raid0b", it will
>still ask me for the root.
>
>The obious fix is that rf_buildroothack() should not set RB_ASKNAME
>and let setroot() use the root specification if it exists, and ask the
>user if it does not. 
>
>That has one drawback. If you have two RAID 1
>  raid0a -> wd0a wd1a, root capable
>  raid1a -> wd2a wd3a, root capable
>And no root specification.
>
>Then rf_buildroothack() would leave the boot device as NULL. setroot()
>will make an attempt. It will discover e.g.: wd0a. So here we get an 
>undesired behavior, because we would have prefered to be asked rather
>than booting on wd0a.
>
>The attached patch changes rf_buildroothack() so that it gets smarter: if
>there are multiple root RAID sets, then rf_buildroothack() will call 
>cpu_rootconf() so that MD code can tell us what is the boot device. Next, 
>we will try to find the RAID set that includes the boot device, and if
>we find one, we use it.
>
>Is it okay to commit that?
>

Why did you change #ifdef DEBUG -> #if DEBUG?

christos