overriding RAIDframe disks as root disks with multiboot

[Klaus Heinz-46]

Hi,

I would like to use the "root" option of the "multiboot" command in
boot.cfg in order to specify which RAIDframe disk should be used as the
root disk.

Unfortunately this does not work at the moment on NetBSD 5 and
NetBSD-current. If the kernel config file does not specify the root disk
at compile time, RAIDframe always takes precedence over everything else.

The appended patch changes this behaviour so that RAIDframe respects
the multiboot command line.

Is my patch machine-independant, ie can I expect <machine/bootinfo.h>
and "lookup_bootinfo(BTINFO_ROOTDEVICE)" to be available on all platforms?
I am not sure whether this file, function and macro is considered part of
the MI/MD interface; section 9 of the man pages does not mention the
term "bootinfo".

ciao
     Klaus


Index: rf_netbsdkintf.c
===================================================================
RCS file: /cvsroot/src/sys/dev/raidframe/rf_netbsdkintf.c,v
retrieving revision 1.250.4.4
diff -u -r1.250.4.4 rf_netbsdkintf.c
--- rf_netbsdkintf.c 4 Apr 2009 17:15:14 -0000 1.250.4.4
+++ rf_netbsdkintf.c 31 Oct 2009 14:47:05 -0000
@@ -163,6 +163,8 @@
 
 #include <prop/proplib.h>
 
+#include <machine/bootinfo.h>
+
 #include <dev/raidframe/raidframevar.h>
 #include <dev/raidframe/raidframeio.h>
 #include "raid.h"
@@ -487,7 +489,7 @@
  /* if the user has specified what the root device should be
    then we don't touch booted_device or boothowto... */
 
- if (rootspec != NULL)
+ if ((rootspec != NULL) || (lookup_bootinfo(BTINFO_ROOTDEVICE) != NULL))
  return;
 
  /* we found something bootable... */

[Manuel Bouyer]

On Sat, Oct 31, 2009 at 08:36:14PM +0100, Klaus Heinz wrote:

> Hi,
>
> I would like to use the "root" option of the "multiboot" command in
> boot.cfg in order to specify which RAIDframe disk should be used as the
> root disk.
>
> Unfortunately this does not work at the moment on NetBSD 5 and
> NetBSD-current. If the kernel config file does not specify the root disk
> at compile time, RAIDframe always takes precedence over everything else.
>
> The appended patch changes this behaviour so that RAIDframe respects
> the multiboot command line.
>
> Is my patch machine-independant, ie can I expect <machine/bootinfo.h>
> and "lookup_bootinfo(BTINFO_ROOTDEVICE)" to be available on all platforms?
> I am not sure whether this file, function and macro is considered part of
> the MI/MD interface; section 9 of the man pages does not mention the
> term "bootinfo".

It's MD. BTINFO_ROOTDEVICE only exists on x86, sandpoint and zaurus.
Also I'm not sure why you want this behavior. If you want to specify the
root filesystem on the command line, don't set raidctl -A root on
the raidframe device.

--
Manuel Bouyer <bouyer@...>
     NetBSD: 26 ans d'experience feront toujours la difference
--

[Klaus Heinz-46]

Manuel Bouyer wrote:

> It's MD. BTINFO_ROOTDEVICE only exists on x86, sandpoint and zaurus.

I suppose we do not want MD code in RAIDframe...

> Also I'm not sure why you want this behavior. If you want to specify the
> root filesystem on the command line, don't set raidctl -A root on
> the raidframe device.

This would only work if all the kernels supported the multiboot command.
NetBSD 3 does not. I have a case where I need "-A root" for NetBSD 3
on one file system and NetBSD 5 on a second raid. Without the multiboot
command NetBSD 5 always tries to boot from the wrong file system.
Another point is, that IMO command line arguments should take
precedence. I was surprised when specifying "root=..." did not work.

ciao
     Klaus

[David Brownlee]

2009/10/31 Klaus Heinz <k.heinz@...>:
> Manuel Bouyer wrote:
>
>> It's MD. BTINFO_ROOTDEVICE only exists on x86, sandpoint and zaurus.
>
> I suppose we do not want MD code in RAIDframe...

I would suggest that BTINFO_ROOTDEVICE might be better classed as "MI
but only implemented on some platforms". Certainly any platform which
*can* pass a rootdev from the bootloader should be implementing it...

>> Also I'm not sure why you want this behavior. If you want to specify the
>> root filesystem on the command line, don't set raidctl -A root on
>> the raidframe device.
>
> This would only work if all the kernels supported the multiboot command.
> NetBSD 3 does not. I have a case where I need "-A root" for NetBSD 3
> on one file system and NetBSD 5 on a second raid. Without the multiboot
> command NetBSD 5 always tries to boot from the wrong file system.
> Another point is, that IMO command line arguments should take
> precedence. I was surprised when specifying "root=..." did not work.

I agree - its somewhat analogous to booting with RB_ASKNAME and
setting the root dev that way - it has been explicitly set, so should
override the raidframe autoconfig.

[Klaus Heinz-47]

David Brownlee wrote:

> I would suggest that BTINFO_ROOTDEVICE might be better classed as "MI
> but only implemented on some platforms". Certainly any platform which
> *can* pass a rootdev from the bootloader should be implementing it...

This raises the question how to determine whether the platform implements
this feature "override rootdev from the bootloader"?

Would a test for "BTINFO_ROOTDEVICE" be ok?
If we restrict the patch to those platforms implementing "multiboot" we
could rely on the macro MULTIBOOT being defined.

ciao
     Klaus

[Klaus Heinz-47]

Hi,

it looks like I am the only one interested in the proposed change, so
I retract the patch and will keep it in my local tree.

ciao
     Klaus

[David Young]

On Sat, Oct 31, 2009 at 08:36:14PM +0100, Klaus Heinz wrote:

> Hi,
>
> I would like to use the "root" option of the "multiboot" command in
> boot.cfg in order to specify which RAIDframe disk should be used as the
> root disk.
>
> Unfortunately this does not work at the moment on NetBSD 5 and
> NetBSD-current. If the kernel config file does not specify the root disk
> at compile time, RAIDframe always takes precedence over everything else.
>
> The appended patch changes this behaviour so that RAIDframe respects
> the multiboot command line.
>
> Is my patch machine-independant, ie can I expect <machine/bootinfo.h>
> and "lookup_bootinfo(BTINFO_ROOTDEVICE)" to be available on all platforms?
> I am not sure whether this file, function and macro is considered part of
> the MI/MD interface; section 9 of the man pages does not mention the
> term "bootinfo".
>
> ciao
>      Klaus
>

> Index: rf_netbsdkintf.c
> ===================================================================
> RCS file: /cvsroot/src/sys/dev/raidframe/rf_netbsdkintf.c,v
> retrieving revision 1.250.4.4
> diff -u -r1.250.4.4 rf_netbsdkintf.c
> --- rf_netbsdkintf.c 4 Apr 2009 17:15:14 -0000 1.250.4.4
> +++ rf_netbsdkintf.c 31 Oct 2009 14:47:05 -0000
> @@ -163,6 +163,8 @@
>  
>  #include <prop/proplib.h>
>  
> +#include <machine/bootinfo.h>
> +
>  #include <dev/raidframe/raidframevar.h>
>  #include <dev/raidframe/raidframeio.h>
>  #include "raid.h"
> @@ -487,7 +489,7 @@
>   /* if the user has specified what the root device should be
>     then we don't touch booted_device or boothowto... */
>  
> - if (rootspec != NULL)
> + if ((rootspec != NULL) || (lookup_bootinfo(BTINFO_ROOTDEVICE) != NULL))
>   return;

IMO, the code from if (rootspec != NULL) to the end of
rf_buildroothack() should be deleted.  Let the MD findroot() code
choose, as it does for every other type of disk.  What am I missing?

Dave

--
David Young             OJC Technologies
dyoung@...      Urbana, IL * [phone]

[Robert Elz]

    Date:        Wed, 11 Nov 2009 14:03:58 -0600
    From:        David Young <dyoung@...>
    Message-ID:  <20091111200358.GP603@...>

  | What am I missing?

Most probably that the MD root finding code just looks for the
drive from which the system booted - last I heard, none of NetBSD's
ports could boot from a (raidframe) raid0 or raid5 - if you want
root to be on one of those then (other than specifying rootdev in the
kernel build) you're stuffed...

That code (I believe) imlements the "ratdctl -A root" functionality,
that marks a raid "device" as a candidate root device - when the kernel
isn't configured for a specific root, the raid filesys is selected.

FWIW, I think the code to allow the user to override that at boot
time would be a useful addition - while it is possible to boot,
"raidctl -A yes" or "raidctl -A no", and then reboot, or perhaps
"boot -a" on systems that support that, but that's a painful
sequence of operations for what should be a simple task.

It should always be
        1. what the user explicitly asks for
        2. what the kernel has built in
        3. hacks like "ratdctl -A root" (or perhaps similar things for cgd etc)
        4. where I think I came from

in that order to find the root device.

kre

[David Young]

On Thu, Nov 12, 2009 at 04:01:06AM +0700, Robert Elz wrote:

>     Date:        Wed, 11 Nov 2009 14:03:58 -0600
>     From:        David Young <dyoung@...>
>     Message-ID:  <20091111200358.GP603@...>
>
>   | What am I missing?
>
> Most probably that the MD root finding code just looks for the
> drive from which the system booted - last I heard, none of NetBSD's
> ports could boot from a (raidframe) raid0 or raid5 - if you want
> root to be on one of those then (other than specifying rootdev in the
> kernel build) you're stuffed...
>
> That code (I believe) imlements the "ratdctl -A root" functionality,
> that marks a raid "device" as a candidate root device - when the kernel
> isn't configured for a specific root, the raid filesys is selected.

Is there any reason that we should not convey a RAID's root candidacy
using a device property, instead?

Dave

--
David Young             OJC Technologies
dyoung@...      Urbana, IL * [phone]

[Robert Elz]

    Date:        Wed, 11 Nov 2009 15:10:50 -0600
    From:        David Young <dyoung@...>
    Message-ID:  <20091111211050.GQ603@...>

  | Is there any reason that we should not convey a RAID's root candidacy
  | using a device property, instead?

Definitely not my call, I don't know enough to comment - though I
think that raidframe predates device properties, so why it
wasn't done that way doesn't need a lot of investigation.

But the implementation method of "raidctl -A root" isn't really
important to the current question, which is "who wins?"  That is,
the ratidctl setting, or the multiboot command line.

kre

[David Young]

On Thu, Nov 12, 2009 at 04:27:02AM +0700, Robert Elz wrote:
> But the implementation method of "raidctl -A root" isn't really
> important to the current question, which is "who wins?"

I think that the implementation method is important because the only
objection to Klaus's patch is that it adds some MD code to RAIDframe.

> That is, the ratidctl setting, or the multiboot command line.

The consensus seems to be that the multiboot command line should
win.

Dave

--
David Young             OJC Technologies
dyoung@...      Urbana, IL * [phone]

[Robert Elz]

    Date:        Wed, 11 Nov 2009 16:00:08 -0600
    From:        David Young <dyoung@...>
    Message-ID:  <20091111220008.GR603@...>

  | I think that the implementation method is important because the only
  | objection to Klaus's patch is that it adds some MD code to RAIDframe.

OK, yes, I see that point - I admit by being confused by that
line of argument, it doesn't seem to me as if finding a rootdev
or boot cmd parsing ought to be (totally) MD - certainly the
method of supplying boot input will be MD, and the finding rootdev
when there is no specification at all will also, but much of
what needs to be done there ought to be handled in an MI way,
including finding a specified device to be root, I can't think of
a good reason why all of that stuff would need to be duplicated
(and possibly different) in each port.

kre