Subject: Re: Two NetBSDs on one (i386) drive
To: Frank van der Linden <fvdl@wasabisystems.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 12/19/2001 21:12:08
    Date:        Wed, 19 Dec 2001 14:52:01 +0100
    From:        Frank van der Linden <fvdl@wasabisystems.com>
    Message-ID:  <20011219145201.A20126@vaasje.org>

  | I'd go for passing the starting sector of the partition along to the
  | next stages. The 2nd stage can then stuff it in an additional boot_info
  | structure, and disksubr.c can then find it from there.

Whatever - anything that indicates which partition would do.

  | The hardest part is how to pass the info up. You'll need to find 2
  | registers to do it (one with a magic value so you'll know that
  | the info is valid, the other one with the value). It might be
  | a bit of a struggle to get that done..

The nice part of this is that you don't need the magic value.  Even if it
is there, it is no guarantee (we're not going to be doing any kind of
cryptographic validation ... ), so you wouldn't want to rely upon it too
much anyway.

The answer is for the consumer (consumers actually) of the info to validate
it for sanity before use.   That is, actually check that it (whatever "it"
happens to be, block number or partition index) actually refers to the start
of a NetBSD partition - and ignore "it" otherwise.

Then, if you have only one NetBSD partition, you get the same behaviour
as now, guaranteed - the boot code & kernel find the NetBSD partition and
use it - perhaps reached in a slightly different way (they might go right
to the partition without needing to search).

If you want to have 2 NetBSD partitions, then you'd need to make sure that
you have boot blocks that do the right thing - without that the 2nd partition
is useless anyway.   In that case, the value passed through will be valid.

The only risk is if you have 2 NetBSD partitions, and bad boot blocks,
that through some fluke, happen to pass in the identifier of the wrong
partition.   In that case you'd boot a different NetBSD than intended.
That shouldn't be a disaster anyway (but simply using any mbr editor to
change the partition type, temporarily, will get round that problem).

For this though, the block number approach is likely better than a small
integer approach (whether the small int is 0..3 or the F1..F4 keycode
value) as there's a smaller chance of it selecting a NetBSD partition by
random chance.

kre