Thanks for the feedback, Kevin.
I don't think I understand the use case you are trying to address.
The use case is one I've got with a few customers who do not want end users to be able to change the boot order manually -- USB is a "last ditch" option, only to be used if all other devices fail, but they don't want users booting from their own USB drives if the other boot options are still functional. Also, these customers all have the same expectation with respect to bootorder: if the first drive is not bootable (even if it is present), then the next drive in the bootorder will be attempted. Thus, if the first drive is present but has no MBR (or its MBR has become corrupt), they expect the second drive to boot. Of course, the second drive can't boot in the current implementation since only the first drive can ever be 0x80.
So, if a scsi drive is made 0x80 this scheme does not work at all, and if a scsi drive is not 0x80 there is no way to boot from it.
You mention SCSI drives, and I'm not as familiar with those as I'd prefer. For this case, there are two options: Disable the Failover or Enable it. If the Failover is disabled, you get the behavior you had before. If Failover is enabled and the SCSI drive is 0x80 and it boots, then the code would progress as before. If Failover is enabled, the SCSI drive is 0x80 and it does not boot, at least the Failover would allow something to boot. As I see it, either the SCSI drive is bootable or not. If it's bootable, Failover makes no difference. If the SCSI drive is not bootable, Failover gives another drive the chance to boot.
On a technical note, the patch has some implementation issues...
I'll review the stuff you mentioned regarding Technical Notes. Certainly the use of "#if" is a style issue and can easily be changed, and the stuff I've got in the EBDA can be moved to global storage. I'm curious, though: Why is it not safe to alter the IDMap in the boot phase? Is it unsafe to allow it to change before the device has actually booted, or is it only unsafe to change once the device has transferred execution to the OS?
Regards, -- Steve G.