Although the current draft version of the Multiboot Specification says that a boot loader can pass I/O ports used by BIOS drives (so that a kernel utilize the information to map BIOS drives to OS devices more reliably), I'm thinking of a different thing.
As you know, the I/O ports method isn't perfect (for example, you cannot distinguish which drive is a master or a slave). The right way is to investigate BIOS drives in more details (e.g. which bus a drive is attached). One way is to do that in the OS level. That is to say, a kernel makes a vm86 environment on its own (as FreeBSD and Linux do), writes magic code to fixed locations of devices, uses BIOS calls to determine which BIOS drive corresponds to which device, and restores the original data. As that above is an OS-level solution, we should consider another approach (I'm not sure if we should, really). Then, I find that INT 13, AH = 48h (GET DRIVE PARAMETERS) gets rich information on a BIOS drive, if your BIOS supports IBM/MS INT 13 Extensions version 2.0 or above. The parameter table supported by 2.0 or above contains the physical I/O port address, disk-drive control port address, etc. With version 3.0, it gets even the interface type (such as "ATA"). Of course, this solution is only for newer machines. But, if there is no perfect way, isn't that acceptable? Okuji _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
