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?