Re: [PATCH v3 10/16] efi: create efi_enabled()

["Jan Beulich" <JBeulich@suse.com>]

>>> On 01.06.16 at 17:23, <daniel.kiper@oracle.com> wrote:
> On Fri, May 27, 2016 at 02:22:39AM -0600, Jan Beulich wrote:
>> >>> On 25.05.16 at 19:15, <daniel.kiper@oracle.com> wrote:
>> > On Wed, May 25, 2016 at 01:20:23AM -0600, Jan Beulich wrote:
>> >> >>> On 15.04.16 at 14:33, <daniel.kiper@oracle.com> wrote:
> 
> [...]
> 
>> >> > --- a/xen/include/xen/efi.h
>> >> > +++ b/xen/include/xen/efi.h
>> >> > @@ -2,15 +2,17 @@
>> >> >  #define __XEN_EFI_H__
>> >> >
>> >> >  #ifndef __ASSEMBLY__
>> >> > +#include <xen/bitops.h>
>> >> >  #include <xen/types.h>
>> >> >  #endif
>> >> >
>> >> > -extern const bool_t efi_enabled;
>> >> > -
>> >> >  #define EFI_INVALID_TABLE_ADDR (~0UL)
>> >> >
>> >> > +#define EFI_PLATFORM	0
>> >>
>> >> So what does "platform" mean? Did you consider using the more fine
>> >
>> > It means "EFI platform". It differentiates from "legacy BIOS platform".
>>
>> Well, that's what was clear from the beginning. The question however
>> was (taken together with the second one) what it means functionality
>> wise. The later addition makes clear it doesn't mean "loaded directly
> 
> This means that we run on EFI platform and we can use its features,
> e.g. runtime services, get info from it about ACPI, SMBIOS, etc.
> 
>> from EFI". But looking at the various flags Linux has here, what
> 
> Yep.
> 
>> functionality does it imply? Does it e.g. mean runtime services are to
>> be used? If so, the flag would need to be cleared when their use if
> 
> As above: not only.

I.e. we're back at me asking you to make this at least a little more
fine grained.

>> being suppressed.
> 
> If we need that (e.g. for ARM) then we should create e.g. EFI_RS.

Why only then? We already can suppress the use of runtime services.

>> >> grained set of flags Linux uses nowadays? That would also eliminate
>> >
>> > I wish to use just basic idea. However, I am not going to copy all
>> > stuff from Linux. We do not need that.
>>
>> We don't need all of it, sure. But some more fine grained
>> identification of what functionality is available / to be used
>> would surely benefit us as a whole and your patch series in
>> particular.
> 
> As above.

Well, above you don't really reason on why this coarse granularity
is good enough. Hence my response can only be: As above.

Jan


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