On Mon, Jul 28, 2014 at 9:10 AM, Jan Beulich JBeulich@suse.com wrote:
On 28.07.14 at 18:04, Ian.Campbell@citrix.com wrote:
On Mon, 2014-07-28 at 17:00 +0100, Jan Beulich wrote:
On 28.07.14 at 17:56, Ian.Campbell@citrix.com wrote:
On Mon, 2014-07-28 at 16:52 +0100, Jan Beulich wrote:
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.
Perhaps we can put the relevant code into efi specific sections and DTRT in xen.lds.S?
Maybe it could be made work, but I'd be wary of linker version issues then.
Rather than arch .c files including common .c (or .inc) files how about making xen/arch/*/efi/Makefile link xen/commmon/efi/built-in.o into it's own built-in.o instead of having xen/common/Makefile do it like would normally happen?
That's an option. But I agree the inclusion of .c in another .c isn't really nice; I would therefore anyway favor a (set of) arch header file(s) providing everything the common code can't do on its own.
Jan
I think I have pretty good handle addressing all of the feedback with the exception of this build issue. Jan - I don't understand your above suggestion. Another way to handle this would be for the x86 EFI code to copy (or link) the efi-shared.c file locally for building, where it's use would be controlled by the PE/COFF toolchain autodetection. It seems that some kind of games will need to be played to have the autodetection cooperate with building shared code.
Thanks, Roy