> > which specifically get the drive's idea of its capacity in sectors.
> My question is how does this info get out of the kernel to a program
> like sysinst or disklabel.

With disklabel(8).  You trust that either it's the default label
(which is correct), or the user has DTRT (or knows more than you do!).

This is not what's broken.

> By the way, I agree with you completely here, either use the int25 or
> calculate the CHS from the start sector.  The problem I see is that
> some yo-yo is going to do a fdisk /mbr or load nt or win95 and its
> going to reinstall the mbr code.  So I'm afraid of going this way.

That's actually not quite the problem.  The boot block *should* do
what I said, simply to make it more reliable, to deal with the case
where the boot block is near the end of a track, and to handle the
case where we have no default MBR at all.

It is however true that fdisk(8) still needs to know the BIOS geometry
in order to calculate the CHS values for the NetBSD MBR partition, so
that the default MBR code can load the first stage correctly.


So I suggest a completely different mechanism.

At boot time, before doing anything else, we do two BIOS calls for
each disk (say, up to 16 disks).  The first loads the first block
(MBR) of the disk, and the second gets the BIOS disk description.  We
store these (or maybe just the geometry and a hash of the first block)
away.

During autoconfig, when we find a disk, we read the first block, look
it up in the table we stashed away, and if found use the geometry we
got from the BIOS.  (If there are multiple matches with different BIOS
geometries, we arbitrarily pick one and warn the user.)

This data is then used to calculate the default label.  If there is a
label present already, we use that instead.

Alternatively, we could have the table passed in from the boot block.
Old users (with old boot blocks) are going to have this right by now
anyway.