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. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
