On Mon, Nov 29, 2010 at 08:55:09PM -0500, Kevin O'Connor wrote:
On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
If scsi card has optionrom with only one bcv then Seabios can determine its boot order from device path, so why not provide user with this option today?
It's unclear to me how SeaBIOS is supposed to do that.
Try to keep track of which bcv/bev belongs to which pci device? It should surely work for devices supported by seabios natively.
No issues for any device with native support. I'm okay with the proposed syntax.
SeaBIOS should also know which device's rom registered which entry.
It doesn't today, but that shouldn't be an issue to add.
It might become tricky though in case there are multiple identical devices are present, say two e1000 cards, where the first rom could register entries for both cards ...
Right - here's where things get complicated.
I don't see how it can be solved at all given that bev->productname doesn't have any structure so it can't be parsed back to device's pci address.
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@i0cf8/ethernet@4/ethernet-phy@0 /pci@i0cf8/rom@4
SeaBIOS will ignore the first entry, and act on the second entry.
SeaBIOS should be able to operate just fine with the first entry. "ethernet@4" means "the nic at bus address 4". As this is a PCI bus "4" is the pci address. So SeaBIOS would just look what entries it has for "00:04.0", run the rom, and ignore the "/ethernet-phy@0" part as it can't handle it.
Right - I'm not happy about trying to parse out openbios device descriptors though. The natural flow (as I see it) is for seabios to find all the boot methods in the system and then see which ones have been requested to be prioritized. Trying to do fuzzy matching of found device to requested device just seems like an unnecessary pain IMO.
When booting via rom it can either just pick the first entry unconditionally (probably good enougth in 99% of the cases) or do some guesswork based on the order the entries are registered.
I guess that's the crux of the matter - I'd rather not do guessing in the firmware. The emulator is in a much better position to do heuristics and guessing - if nothing else, the emulator can allow the user to pass it in on the command-line.
Actually Seabios is in a much better position to do this heuristics since only at runtime all IPLs are knows. What heuristics you think emulator can implement?
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?
fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
Bus is specified via location in the tree, i.e. you'll see the bridge for the secondary pci bus in the path, like this:
/pci@i0cf8/bridge@7/ethernet@3/...
(not sure it is actually named 'bridge' in the openfirmware specs though).
Thanks.
-Kevin
-- Gleb.