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

H.J. Lu hjl.tools@gmail.com
Fri Jun 26 12:52:47 GMT 2020


On Thu, Jun 25, 2020 at 6:20 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 25, 2020 at 05:30:59AM -0700, H.J. Lu wrote:
> > On Thu, Jun 25, 2020 at 09:33:26AM +0200, Florian Weimer wrote:
> > > * H. J. Lu via Libc-alpha:
> > >
> > > >> is not expected to be extendable. The macro API is not my favorite way of
> > > >
> > > > We can expand the cpuid array.  We just need to add an alias to
> > > > __x86_get_cpu_features
> > > > with a new symbol version.
> > >
> > > Agreed, from a GNU gABI perspective.
> > >
> > > However, for some distributions, this requirement will put hardware
> > > enablement for new CPUs on hold until we have reworked our package
> > > dependency generation, so that we can express symbol-specific version
> > > information.  Debian & downstreams can already do this, with some manual
> > > work, but Fedora & downstreams can only express versions on sonames.
> > > (Without these changes, we would have to backport the entire GLIBC_2.33
> > > symbol set to get __x86_get_cpu_features@GLIBC_2.33, for example.  This
> > > is not something we will be able to do in all cases, depending on the
> > > other changes that are going in.)
> > >
> > > Even then, we can only backport such changes if a glibc release has
> > > happened (so that we can be sure that the meaning of the symbol version
> > > will not change again).
> > >
> > > My proposal, where the index is passed to the function and the function
> > > returns the flag word, does not have these issues: old glibcs will
> > > simply return 0 flags, and the feature appears unusable/unavailable.
> > > This is what already happens with your approach, too, if we use more
> > > bits inside the existing array elements.
> > >
> > > I'm not entirely opposed to enhancing the RPM dependency generation, but
> > > I already tried once and couldn't get it done, and if I fail again, it
> > > might seriously impact CPU hardware enablement in Red Hat Enterprise
> > > Linux 9.  I hope this explains my reservations about this interface
> > > design.
> > >
> >
> > Thanks for your detailed explanation.  Here is the revised patch.
> > COMMON_CPUID_INDEX_MAX and USABLE_FEATURE_INDEX_MAX are passed to
> > __x86_get_cpu_features so that when USABLE_FEATURE_INDEX_MAX or
> > COMMON_CPUID_INDEX_MAX are increased to support new processor features,
> > __x86_get_cpu_features in the older glibc binaries returns NULL and
> > HAS_CPU_FEATURE/CPU_FEATURE_USABLE return falses on the new processor
> > feature.  No new symbol version is neeeded.
> >
> > Any comments?
> >
>
> Small update:
>
> const struct cpu_features *
> __x86_get_cpu_features (unsigned int max, int cpuid)
> {
>   if (cpuid)
>     {
>       if (max > COMMON_CPUID_INDEX_MAX)
>         return NULL;
>     }
>   else if (max > USABLE_FEATURE_INDEX_MAX)
>     return NULL;
>   return &GLRO(dl_x86_cpu_features);
> }
>
> Don't return NULL when checking the cpuid array when COMMON_CPUID_INDEX_MAX
> is unchanged, but USABLE_FEATURE_INDEX_MAX is changed.
>

Thanks for the feedbacks.  The latest patch:

https://sourceware.org/pipermail/libc-alpha/2020-June/115397.html

can be expanded to detect more CPU features without new symbol
versions.  Macros compiled against newer glibc headers will simply
return zero at run-time with older glibcs.  If there are no further
comments, I will check it in tomorrow.

-- 
H.J.


More information about the Libc-alpha mailing list