On Mon, Jul 16, 2012 at 07:18:01AM -0600, Steve Goodrich wrote:
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.
If checking for an MBR is sufficient to determine if the drive is "bootable" then I'd suggest adding an option to read and validate the MBR in the POST phase prior to assigning a drive id to it.
[...]
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?
The BIOS specs call for making the f-segment read-only after the POST phase ends. This is implemented under QEMU (and only on QEMU). The "IDMap" variable (along with all variables marked with VAR16) is stored in the f-segment.
-Kevin