> I'd like to be able to have two distinct NetBSD setups on one i386
> drive.

Yes - I was just deciding that was the safest was to test 'current'.
(especially when i've introduced my own bugs to it)
> 
> At the minute it isn't possible (well, not cleanly) because both /boot
> and the kernel find the root by searching the partition table for a
> NetBSD partition, and assuming that the first they find is it.

Uggg - hadn't found that one yet, thought only ms did that trick
> 
> I think an easy way to adjust this (easy for someone who understands
> i386 instructions anyway, which isn't me), is for the search to start
> at N, and do N%4 (N+1)%4 (N+2)%4 and (N+3)%4  - when N is 0, that's
> exactly what happens now, when it isn't, then it will allow a different
> NetBSD root to be found by setting N to be something different than 0.

too complex!  just bung the expected start sector into the relevant boot
block.  Code could 'use first found' if specified sector isn't the
start of a partition.

Once into the partition boot I suspect the code is all part of netbsd
and the relevant value can be passed through.

Would be useful to add support for the windows extended partition at
the same time (at least assuming the standard config where (I believe)
each extended partition contains 1 data partition and another extended one).
> 
> Then, we can take N to be something passed in from the lower level boot
> code (mbr -> 1st stage boot -> 2nd stage boot -> kernel).

Where are the sources for the 1st and 2nd stage boots?
(just to save a massive grovel through the source tree)
> 
> This is safe, even with current boot code that does none of this, as
> currently we assume only one NetBSD partition (slice in other people's
> terminology) per drive.   That is, where the search starts makes no
> difference, except to how many iterations around the loop it takes
> (which is bounded at 4 anyway...).   Of course, it would mean that
> putting two NetBSD partitions on a drive would be a poor idea if there
> were no boot blocks to support it.
> 
> After that, all that's left is for the mbr code to leave the partition
> number it is booting somewhere for the later boot stages to find.  I know
> space there is very tight (especially in the boot selector version), but

I deleted about 17 bytes from the boot selecter version while fixing
a bug in the timeout code - so it isn't as tight as it used to be.
(when the source get updated)

> fortunately, very very little is going to need to be added, as the mbr code
> is already having to find the partition to boot from - all it needs to do
> is save that - we could use almost any value that is good for the mbr code
> as the "which partition" flag, it doesn't have to be 0 1 2 3 at that stage.

The mbr code doesn't search by partition type, the required partition number
is written into the end of the sector by fdisk (I think it is fdisk..)

If the code that writes the pbr did the same, the value could be passed
straight into the kernel.  Assuming netbsd always boot using a netbsd pbr. 
> 
> If there is prior art, from some other boot system, in how to pass this
> info through, then it would be good to copy it of course - that way people
> who use that other boot system instead of NetBSD's mbr code would win as well.

Dunno....  Unixware would boot a unix from a different disk than the pbr!
> 
> Note all of this is a fairly safe and painless change - for anything to
> actually alter from the current state of the world, three things would
> have to happen - the low level boot code would have to save the boot
> partition somewhere (or that somewhere would have to accidentally be set
> to a suitable value .. which could happen of course) - the upper level boot
> code & kernel would have to be updated to use the value passed in (after
> testing it for sanity of course), and there would have to actually be 2
> NetBSD partitions on the drive.
> 

I think the mbr code jumps straight into the pbr, and then into the 2nd
stage boot.  So the registers can be used to pass the info through.
Bi-directional backwards compatibility, and the ability to boot clones
of partitions are the only real difficulties.

x86 instructions aren't hard - just brain dead.  Using the correct bios
calls is more tricky.

    David 

    David