On 28.07.14 at 17:41, Ian.Campbell@citrix.com wrote:
On Wed, 2014-07-23 at 17:31 +0100, Jan Beulich wrote:
-static EFI_BOOT_SERVICES *__initdata efi_bs; static EFI_HANDLE __initdata efi_ih; -static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdOut; -static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdErr;
In the end I'm not really happy anyway with them becoming non- static - rather than building separate .o-s in the common efi/ directory, would it not be possible to just have the .c files there, but include them from the arch ones?
That alternative seems pretty gross to me, what is the problem with a global EfiStdOut or something like that?
It's not a big problem, but I still prefer to avoid making symbols global whenever possible.
This would also address the tool chain detection issue you described in the cover letter (without the addressing of which I can't see how things will ultimately work).
In the case where the toolchain doesn't EFI won't the unnecessary code built in xen/common/efi simply get discarded by the linker?
Not that I'm aware of - afaik no code or data inside a .o would ever get thrown away by the linker without it being specifically asked to do so.
Even if not it looks like ~20K of mostly __init stuff, which doesn't seem like the end of the world, especially given that more and more toolstacks do support EFI with time.
Right now - with the runtime code not moved over yet - it's mostly __init. Plus (with the linker not being able to discard that code) it carries the risk of having references to symbols that don't exist in the non-EFI build.
Jan