Re: [PATCH 05/18] efi: split efi_enabled to efi_platform and efi_loader

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 27/03/15 13:43, Jan Beulich wrote:
>>>> On 27.03.15 at 14:32, <daniel.kiper@oracle.com> wrote:
>> On Fri, Feb 20, 2015 at 04:17:35PM +0000, Jan Beulich wrote:
>>>>>> On 30.01.15 at 18:54, <daniel.kiper@oracle.com> wrote:
>>>> We need more fine grained knowledge about EFI environment and check
>>>> for EFI platform and EFI loader separately to properly support
>>>> multiboot2 protocol.
>>> ... because of ... (i.e. I can't see from the description what the
>>> separation is good for). Looking at the comments you placed
>>> aside the variables doesn't help me either.
>>>
>>>> In general Xen loaded by this protocol uses
>>>> memory mappings and loaded modules in simliar way to Xen loaded
>>>> by multiboot (v1) protocol. Hence, split efi_enabled to efi_platform
>>>> and efi_loader.
>>> And if I'm guessing things right, then introducing efi_loader but
>>> leaving efi_enabled alone (only converting where needed) would
>> efi_enabled is not fortunate name for new usage. Currently it means
>> that Xen binary have or does not have EFI support build in. However,
>> if we build in multiboot2 protocol into xen.gz then it means that
>> it can ran on legacy BIOS or EFI platform. So, I think that we
>> should rename efi_enabled to efi_platform because it will mean
>> that Xen runs on EFI platform or not.
> I disagree here.
>
>> efi_loader is used to differentiate between EFI native loader
>> and multiboot2 protocol.
> And I agree here.

I suppose "built with efi support" is known because of CONFIG_EFI or 
not, and doesn't need a variable.

However, "booted legacy" vs "booted EFI" does need distinguishing at 
runtime, as either is possible.

~Andrew