Re: [Xen-devel] [PATCH V2 01/12] Create efi-shared.[ch], and move string functions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.07.14 at 17:41, <Ian.Campbell@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel