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

[Florian Weimer <fweimer@redhat.com>]

* 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,
Florian