[SeaBIOS] [PATCHv6 00/16] boot order specification

[Kevin O'Connor]

On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> > It's unclear to me how SeaBIOS is supposed to do that.
> > 
> Suppose we have "/pci at i0cf8/scsi at 3/disk at 0,0" with boot index 5 in
> boot devices list and suppose pci device in slot 3 function 0 has
> optionrom. When Seabios load the option rom from device to memory it looks
> for string that matches "/pci at i0cf8/.*@3.*" if the string is found option
> rom gets boot index from it. In our case "/pci at i0cf8/scsi at 3/disk at 0,0"
> will match and optionrom will get boot index 5. In practice Seabios will
> know that device is SCSI by reading device class so it will be able
> to construct string "/pci at i0cf8/scsi at 3" and use simple strstr to find
> matching device path.

I recognize that if we had a regex engine in seabios this would work,
but I'm reluctant to add one.  strstr doesn't work becuase "@3" could
match some unrelated part of the path (eg, don't want to match
"/pci at i0cf8/scsi at 1/disk at 3,0") - so, what you seem to want is
"/pci at i0cf8/[^/]*@3(/|$)".

[...]
> > I'm still stuck on how seabios is supposed to know it's an ethernet
> > card.  Sure, seabios could hardcode translations from classid to
> > strings, but that seems fragile.  What happens when the user wants to
> > boot from myranet, or fiberchannel, or whatnot?
> This is not fragile since class to name translation is defined
> by the spec. But even that is not required if Seabios will be a
> little bit smarter and will implement fuzzy matching. i.e do not
> match "/pci at i0cf8/ethernet at 4/ethernet-phy at 0" exactly but match
> "/pci at i0cf8/.*@4.*" instead.

I think we're agreeing here that we don't want to put class to name
translation in seabios.  :-)

> > Maybe we can compromise here - if the user selects booting from a
> > device, and qemu sees there is a rom for that device, then qemu can
> > specify two boot options:
> > 
> > /pci at i0cf8/ethernet at 4/ethernet-phy at 0
> > /pci at i0cf8/rom at 4
> > 
> This patch series implement device paths as defined by Openfirmware
> spec. /pci at i0cf8/rom at 4 sould be out of spec. But I do not see why Seabios
> can't build later from the former. Also I do not see why it would be
> needed at all.

The name isn't important to me - call it something else if you want.
It's value is that SeaBIOS doesn't then need to do fuzzy matching or
parsing of the device names.  That is, we turn the list from boot
devices to boot methods which makes life easier for the firmware.

> > SeaBIOS will ignore the first entry, and act on the second entry.  If
> > at some later point seabios knows how to natively boot from the device
> > (eg, scsi), then it will use the first entry and ignore the second.
> > 
> 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 at i0cf8/ethernet at 4/ethernet-phy at 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?

> > BTW, how are PCI locations specified in these paths?  They should have
> > a (bus, dev, fn) - your examples only seem to show dev.  How are the
> > other parts specified?
> > 
> Bus numbers are assigned by a guest. Qemu knows nothing about them, so
> it specify device path by topology.  If pci bridge is present device
> path will look like this:
> /pci at i0cf8/pci at 2/ethernet at 4,1/ethernet-phy at 0.
> This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge
> in slot 2 fn 0 of host pci controller. Same is true for usb bus.

I understand - it makes sense.  This does mean that seabios will need
to track where each pci bus comes from.

-Kevin