[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: future of the libc6.1-alphaev67 package



On 2021-08-25 07:46, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 8/24/21 10:59 PM, Aurelien Jarno wrote:
> > With the removal of the libc6-xen package in glibc 2.32, the only
> > package still using the hwcap infrastructure is libc6.1-alphaev67.  The
> > hwcap infrastructure consists in upstream support for looking for
> > libraries in the hwcap directories, plus Debian specific patches to
> > support disabling hwcap with the /etc/ld.so.nohwcap, plus some mechanism
> > in the maintainer scripts to disable hwcap support until all libc6
> > packages are configured.
> > 
> > The various optimized packages have been replaced with time by other
> > mechanisms such as indirect function support (IFUNC), or runtime atomic
> > selection in GCC (-moutline-atomics).
> 
> Isn't this type of architecture optimization support currently seeing a
> revival due to many distributions looking into providing optimized x86_64
> variants? [1]

Yes, but that's unrelated. The plan is not to drop the hwcap mechanism
from upstream code (which btw got extended in glibc 2.33). That will
still be supported for instance for scientific libraries like in the
link you provided. The goal is to stop providing optimized glibc through
the hwcap mechanism (as the optimization is done using GCC or GNU IFUNC
for many architectures), so that we can get rid of all the code enabling
safe upgrade of the libc6 package. This part is Debian specific because
we need to support online upgrades, so version version mismatch between
base and hwcap libraries must not happen.

If optimizations for the ev67 CPU is essential, an alternative is to
ship both the base and hwcap versions in the same libc6.1 package. This
causes an additional 4 MiB of possibly useless files to be installed on
a system, something that has been considered too big for other
architectures. Before going that way, we should check if the resulting
optimization is worth the hassle, especially that we have to disable bit
rotting assembly code from upstream (both baseline and alphaev67
optimized) to get the testsuite passing.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: