Date:        Wed, 19 Dec 2001 13:24:24 -0000
    From:        "David Laight" <David.Laight@btinternet.com>
    Message-ID:  <001b01c18890$7adc2340$0100a8c0@snowdrop>

  | too complex!  just bung the expected start sector into the relevant boot
  | block.

It doesn't really matter what the indicator is, block number, partition
index, or keycode from the bios that selects the partition - what counts
there is saving mbr code space.

  | Code could 'use first found' if specified sector isn't the
  | start of a partition.

yes, that loop has to exist anyway, so we may as well just use it...

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

Yes.

  | 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).

I don't believe they're bootable, so they're not really relevant.
Accessing them is no problem - the NetBSD disklabel (once it is found)
simply refers to a part of the drive that occupies the same space...

  | Where are the sources for the 1st and 2nd stage boots?

The mbr code (both versions) lives in fdisk (/usr/src/sbin/fdisk)
The boot code (both parts are one source) is in /usr/src/sys/arch/i386/stand
(and then biosboot in there is the appopriate one, plus the lib code, etc)

  | (just to save a massive grovel through the source tree)

If you have the locate database build, "locate mbr" and "locate boot"
and a little thought applied to the results find them pretty quickly.

  | 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)

That's good.

  | 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..)

Well, the basic mbr code searches for the active partition.  The selector
version takes whatever the user types (the thing put there by fdisk is the
default user typing, in case the user types nothing) - which can be "enter"
in which case this version also picks the active partition.

The way the mbr code works now is just fine - all that's needed there is for
it to save an indication of the partition it selected for later use.

  | 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. 

Yes, none of this is very difficult, other than figuring out what other
boot systems do, so we can be as compatible as possible.

  | 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.

Yes, that's how the drive number gets passed from the mbr - after that
things start using more conventional arg passing using a stack.   It isn't
the mechanism of how to do it that is really important - more whether it
should be done, and then if there's someone to do it.

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

The bios calls aren't relevant here, they're already done...   And yes, I
suspect that if I wanted, I could work out how intel processors actually
work.   But I have managed to retain my purity in that area for a long time
now, and I would prefer not to sacrifice it if possible.   Especially since
I'm quite sure that learning to program intel processors by playing with boot
blocks wouldn't be the ideal introduction to the architecture.

kre