[Qemu-devel] Re: [PATCHv6 00/16] boot order specification

[Kevin O'Connor <kevin@koconnor.net>]

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