[SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support

[David Woodhouse]

On Fri, 2013-02-08 at 18:02 -0500, Kevin O'Connor wrote:
> 
> Yes - that's why it doesn't make sense to change the Kconfig settings
> of the various qemu drivers from "depends on QEMU" to "depends on
> !COREBOOT" - the CSM is in the same situation as Coreboot.  It's fine
> to access the hardware when under QEMU, but not when running on real
> hardware, and thus the driver should depend on "QEMU".

I think we should focus on fixing this.

You'll not that COREBOOT vs. QEMU was *already* a choice; switching from
'depends on QEMU' to 'depends on !COREBOOT' was a no-op except for the
CSM implications. And yes, for one of those (PMTIMER) I've *already*
gone back and removed that bogus dependency completely.

I don't think we need a massive refactoring of the config. Let
CONFIG_QEMU mean that the system is actually started natively as the
Qemu firmware. If you want to add a separate config option for "may run
under Qemu even though it's a CSM or COREBOOT build", then add that
separately.

I'm not sure what would depend on that. The virtio drivers don't need
to. You just won't find those devices on real hardware. And hell, if
someone actually makes real hardware that behaves like a virtio block
device, why *shouldn't* it work?

I think the only use case is for enabling the lsi SCSI and whatever the
other driver was that was only ever tested on the qemu emulation?

Certainly I think that's true for CSM. In the Coreboot case, is there
anything else qemu-specific that you should be doing yourself, rather
than letting Coreboot sort it out for you?


-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://www.seabios.org/pipermail/seabios/attachments/20130208/021d3a3b/attachment.bin>