Gerd Hoffmann wrote:
>> -drive if=virtio,id=sys,file=/path/to/disk.img
>> -cdrom /path/to/install.iso
>> -boot order=[sys],once=d,menu=off
> Yes, this looks powerful and clean. One could even still define probe
> orders like "-boot order=[sys][backup]d".
Well, except that boot orders with two hard drives in there don't work
in the PC world ...
That depends on your bios. I've seen many that allow disk boot ordering,
though they may not support "[sys]d[backup]".
However, I see no technical reason for artificially restricting qemu
bios capabilities.
>>> - This is just an implementation detail: Do we really need to implement
>>> booting from virtio and scsi via an extension rom? Isn't it
possible
>>> to merge the corresponding support into the main bios?
>> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
> Ok, but that's only an argument to have extboot as a workaround for
> bioses not yet supporting scsi and virtio natively, isn't it? I'm
> thinking long-term here, not arguing against a extboot-based short-term
> solution.
I think it would be useful. Adding a fw_cfg knob to signal 'please boot
via extboot protocol instead of ide disk' should be enougth to allow
bioses supporting extboot directly. Additional plus is we can probably
code it in C not asm then.
I'm still not convinced we need extboot for all bioses on the long term.
And I think we should define new interfaces in a way that finally makes
it obsolete, at least for our "home bios" (whatever it will be).
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux