On 07.08.14 at 01:55, roy.franz@linaro.org wrote:
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:
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.
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.
The process would be - move all files containing pieces you want to re-use from arch/x86/efi/ to common/efi/, with no other changes than to make them build again - possibly in a step by step manner, replace any code portions not suitable for non-x86 by inline functions placed in said header - add ARM variants of anything moved to the x86-specific helper header (and possible empty x86 variants of stuff ARM needs that x86 doesn't)
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.
Yes, that would be an option too, with the linking done in a prerequisite build step. While I generally dislike this model, I do see its simplicity being a possible advantage here.
Jan