On Mon, May 16, 2011 at 09:44:28AM +0100, Ian Campbell wrote:
On Sat, 2011-05-14 at 14:36 +0100, Kevin O'Connor wrote:
On Fri, May 13, 2011 at 04:59:03PM +0100, Ian Campbell wrote:
As you may know we (the Xen project) are hoping to transition to SeaBIOS at the same time as we transition to the recently upstreamed qemu support for Xen.
[...]
Just so I understand, is this needed for Xen pre-qemu integration, post-qemu integration, or both?
We'd like to have all the pieces in place for the Xen 4.2 release, which isn't really planned out yet, but I think the late end of this year would be a reasonable bet. I think we can be flexible around the order integration happens in, we simply won't flip the default until everything is in place.
Is that what you meant by post/pre-qemu integration?
I was referring to your statement above about "transition to SeaBIOS at the same time as we transition to the recently upstreamed qemu support for Xen". I wasn't sure if your patches are tied to that "upstreamed qemu" work or not.
One problem I have with the first patch is that I'm lacking the vocabulary to describe the configuration which is currently represented by COREBOOT=n. I wanted to switch the coreboot option to a Kconfig choice (so I can add XEN as another option) so I needed a name for the other option. I went with GENERIC but I've no idea if that is accurate. Is "EMULATOR" more accurate? Suggestions welcome.
The preferred approach would be to autodetect Xen at runtime and use that to control the code flow. A CONFIG_XEN option would then only be used to reduce the overall code size for those that do not need Xen support and want a smaller binary.
Sure. I'll change things to do it that way then.
As well as CONFIG_XEN should I be adding a xen_present variable which is set dynamically and used as appropriate? If so then is a #ifdef to define it to 0 in the !CONFIG_XEN case (to allow the dead code to be eliminated) necessary?
Thanks.
I'd suggest something like a "int usingXen(void)" inline which reads "xen_present". The first couple of lines of usingXen() could do a "if (!CONFIG_XEN) return 0". Though - if the code is as simple as the patches you've already sent - then you can leave it on permanently for emulators (ie, do "if (CONFIG_COREBOOT)") - I'm not worried about a few extra bytes for Xen in the emulator case.
Or is gcc's whole program optimisation smart enough to spot when a global variable is never set != 0 and eliminate code as necessary?
I don't think it's that smart.
-Kevin