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 "/p...@i0cf8/s...@3/d...@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 "/p...@i0cf8/....@3.*" if the string is found option > rom gets boot index from it. In our case "/p...@i0cf8/s...@3/d...@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 "/p...@i0cf8/s...@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 "/p...@i0cf8/s...@1/d...@3,0") - so, what you seem to want is "/p...@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 "/p...@i0cf8/ether...@4/ethernet-...@0" exactly but match > "/p...@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: > > > > /p...@i0cf8/ether...@4/ethernet-...@0 > > /p...@i0cf8/r...@4 > > > This patch series implement device paths as defined by Openfirmware > spec. /p...@i0cf8/r...@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 /p...@i0cf8/ether...@4/ethernet-...@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: > /p...@i0cf8/p...@2/ether...@4,1/ethernet-...@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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
