docs/bios_mapping.txt

BIOS Device Mapping Techniques


NOTE:  This is only necessary to do for hard disks.  Floppies are
  already easy to determine.  (IDE are in the order of "Master from
  controller on INT 14, Slave from controller on INT 14, Master from
  controller on INT 15, and Slave from controller on INT 15, and
  always come before SCSI)


Both of these techniques should be usable from any PC OS, and neither
require any special support in the drivers themselves.  This document
will be flushed out into detailed explanations, particularly for #2
below.

The general rule is that technique #1 is the quick and dirty solution.
It works most of the time, but doesn't cover all the bases, and is
relatively simple.

Technique #2 is much more complex, but it has potential to solve the
problem under all conditions, plus allow access of the remaining
BIOS devices when not all of them have OS drivers.


-- BIOS device mapping technique #1 --

Before activating ANY of the device drivers, gather enough data
from similar sectors on each of the disks such that each one can be
uniquely identified.

After activating the device drivers, compare data from the drives
using the OS drivers.  This should hopefully be sufficient to provide
such a mapping.

Problems:  (1) The data on some BIOS devices might be identical (so
the part reading the drives from the BIOS should have some mechanism
to give up), and (2) There might be extra drives not accessible from
the BIOS which are identical to some drive used by the BIOS (so it
should be capable of giving up there as well).


-- BIOS device mapping technique #2 --

This first step may be unnecessary, but first create copy-on-write
mappings for the device drivers writing into PC RAM.  Keep the original
copies for the "clean BIOS virtual machine" to be created later.

For each device driver brought online, determine which BIOS devices
become inaccessible by:

  -- Creating a "clean BIOS virtual machine".
  -- Set the I/O permission map for the I/O area claimed by the device driver
     to no permissions (neither read nor write).
  -- Access each device.
  -- Record which devices succed, and those which try to access the
     "restricted" I/O areas (hopefully, this will be an "xor" situation).

For each device driver, given how many of the BIOS devices were subsumed
by it (there should be no gaps in this list), it should be easy to
determine which devices on the controller these are.

In general, you have at most 2 disks from each controller given BIOS numbers,
but they pretty much always count from the lowest logically numbered devices
on the controller.