On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
If you let go to the idea of exact matching of string built by qemu in Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0 provides everything that Seabios needs to know and even more. If you ignore all the noise it just says "boot from pci device slot 4 fn 0". Seabios may have native support for the card in the slot or it can use option rom on the card. Qemu does not care.
I'm having a hard time letting go of string matching. I understand all the info is there if SeaBIOS parses the string. However, I think parsing out openbios device strings is overkill in an x86 bios that just wants to order the boot objects it knows about.
Is there an issue with qemu generating two strings for devices with roms?
I just do not see how I can justify this addition to qemu maintainers given that the parsing code below is very simple.
It doesn't look correct to me - it doesn't handle the case where the PCI device is on a bridge.
BTW, what's the plan for handling SCSI adapters? Lets say a user has a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3 bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from lun3. I understand this use case may not be important for qemu, but I'd like to use the same code on coreboot. Being able to boot from any drive is important - it doesn't have to autodetect, but it should be possible.