> The mechanisms for making BIOS geometries available to the kernel are
> there, but they're not being used at the moment.

Whew. At least there's hope. How much info is available on the BIOS side?
Can we get at things like Manufacturer ID strings, or just the C/H/S numbers?

> The major problem is that you can not make a 100% proof connection
> between BIOS drive numbers and NetBSD numbers.

True. But I'm willing to bet that we can get 99% of the time. Perhaps by
doing something evil like checksumming a few key blocks of the disk from
the BIOS side, and then tunneling that information into the installer
program. While it won't _always_ work, it would work often enough to make
life easier for many people. When it doesn't, people can either resort to
the old "papel & calculator" technique or they can 'tag' the disk somehow,
say by using disklabel or DOS format to modify the disk in some unique way
(could be as simple as naming it something other than "mydisk" !).

Even simple things like the size of the disk would, on many systems,
be enough for people to "connect the matching drive profiles" and have
plenty of confidence in it. I have two disks: a 2 Gig and a 4 Gig. It
would definitely work for me. And on a single-disk system it would be
trivial.

It's more important that each disk "looks different" from every other disk
at both BIOS probe time and NetBSD probe time, and that they "look like
themselves" after NetBSD boots so that we can match them up in the install
program.

It's also critical that we display the complete set of disk mappings and
allow the user to override our analysis in case anything went wrong.

> Also, nothing stops a user from compiling a kernel with wd0 being the
> 2nd IDE disk, and wd1 being the first.

True, although I am less concerned about this during installation because
people don't normally mutate the installation kernel very much. We have
more to fear from smarty-pants BIOS's (like the Adaptec BIOS on my machine)
that let you pick the boot SCSI device, which then magically occupies the
C-drive position and the other drives fall into place after it. This just
illustrates your point above, that mapping the BIOS drive list to the
NetBSD drive list is a problem whose solution is not closed-form.

> Having said that, the current method clearly needs improvement, and the
> above probably would be better, with the option for the user to check
> things. Although most people do not seem to do this.

Huh? Perhaps the reason people don't check is because they aren't presented
with enough information for them to spot anything they recognize, so they
just flip a coin and hope for the best.

If the installer printed the 'dmesg' output for each disk next to the
selection list, that would be more than enough (on my system, and probably
on a lot of people's systems) for me to know which disk it is. If the BIOS
information that was collected also tells me whatever it can about the disk,
then I've probably got enough information to make the judgement call.

Gawd, how it would be nice if we could query all drives for a serial number.

Todd Whitesel
toddpw @ best.com