V3: [PATCH] x86: Install <sys/platform/x86.h> [BZ #26124]

[Florian Weimer]

* H. J. Lu:

>> accessed without relocations.  __builtin_cpu_supports does not have this
>> issue.
>>
>> The manual does not explain the difference between “available” and
>> “usable”.  I do not think we should expose both.  I don't see any
>> circumstances under which “available” would provide useful information.
>
> Fixed.  "available" means supported by the operating system, which is
> very useful information.

The manual update contradicts that.  It says that “usable” is what
implies operating system support.  I hope the manual is correct. 8-)

“usable” is obviously useful.  As far as I understand it, if the flag is
set, all preconditions for using the feature are met, and attempting to
use it will not trap (unless there are memory faults etc.).

Does “available” means that the feature could become “usable” merely as
the result of configuration changes, or hypervisor and kernel software
updates?  Why is that useful information?  Is it even reliable?

I have not seen this distinction on any other architecture.

>> struct cpu_features (even in its reduced form) is fairly large.  We will
>> never be able to reduce its size again if it becomes public ABI.
>
> Fixed by
>
> struct cpu_features
> {
>   struct cpu_features_basic basic;
>   unsigned int *usable_p;
>   struct cpuid_registers cpuid[COMMON_CPUID_INDEX_MAX];
> };

I think the cpuid member is the fat part.  But the pointer indirection
allows us to grow the *usable_p part without having to duplicate the
backing storage for __x86_get_cpu_features, so it is an improvement.

> __builtin_cpu_supports is equivalent to CPU_FEATURE_USABLE and it
> doesn't support HAS_CPU_FEATURE which does provide useful information.

I'm still puzzled as to why you aren't extending the existing function.

Thanks,
Florian