[PATCH] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[PATCH] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Carlos O'Donell]

The "Hardware capabilities" section is seeing an update in upstream
glibc as we review how the search directories are handled between
the various architectures. In the meantime we should update the man
page to reflect the current set of search paths for all supported
target machines.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>
---
 man8/ld.so.8 | 296 +++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 278 insertions(+), 18 deletions(-)

diff --git a/man8/ld.so.8 b/man8/ld.so.8
index f34eca3d8..8b651f9e9 100644
--- a/man8/ld.so.8
+++ b/man8/ld.so.8
@@ -746,36 +746,296 @@ Some shared objects are compiled using hardware-specific instructions which do
 not exist on every CPU.
 Such objects should be installed in directories whose names define the
 required hardware capabilities, such as
-.IR /usr/lib/sse2/ .
-The dynamic linker checks these directories against the hardware of the
-machine and selects the most suitable version of a given shared object.
-Hardware capability directories can be cascaded to combine CPU features.
-The list of supported hardware capability names depends on the CPU.
-The following names are currently recognized:
-.\" Presumably, this info comes from sysdeps/i386/dl-procinfo.c and
-.\" similar files
+.IR /usr/lib64/haswell/ .
+The dynamic linker checks these directories against the hardware of the machine
+and selects the most suitable version of a given shared object.  Hardware
+capability directories can be cascaded to combine CPU features.  The list of
+supported hardware capability names depends on the CPU.  The list of supported
+hardware capability names may change with each release of the C library and is
+considered an optimization, and should not be relied upon for correct operation
+of the application. Applications should provide a default non-optimized
+implementation that is installed in the default library search paths.
+Care should be taken when packaging such application with a package manager,
+particularly the scenario where an optimized library is being removed.  With
+certain package managers, particularly rpm, the newer version of the
+application is installed first, which means that for a period of time during
+the upgrade all applications that use the library may start with a mixed set of
+libraries e.g.  the old library from the feature-based search path, and new
+libraries from the upgrade. To avoid this scenario the new library version
+should delete all known optimized libraries in the post-install phase.
+.TP
+The following names are currently recognized as of the release of glibc 2.31:
+.\" This information comes from glibc's sysdeps/*/dl-procinfo.c and is
+.\" currently not directly documented in the glibc manual. We document
+.\" it here with the help of the glibc maintainers.
 .TP
 .B Alpha
-ev4, ev5, ev56, ev6, ev67
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+ev4,
+ev5,
+ev56,
+ev6,
+ev67
+.TP
+.B Arm AArch32
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+26bit,
+aes,
+crc32,
+crunch,
+edsp,
+evtstrm,
+fastmult,
+fpa,
+half,
+idiva,
+idivt,
+iwmmxt,
+java,
+lpae,
+neon,
+pmull,
+sha1,
+sha2,
+swp,
+thumb,
+thumbee,
+tls,
+vfp,
+vfpd32,
+vfpv3,
+vfpv3d16,
+vfpv4
+.TP
+.B Arm AArch64
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+aes,
+asimd,
+asimddp,
+asimdfhm,
+asimdhp,
+asimdrdm,
+atomics,
+cpuid,
+crc32,
+dcpop,
+dit,
+evtstrm,
+fcma,
+flagm,
+fp,
+fphp,
+ilrcpc,
+jscvt,
+lrcpc,
+paca,
+pacg,
+pmull,
+sb,
+sha1,
+sha2,
+sha3,
+sha512,
+sm3,
+sm4,
+ssbs,
+sve,
+uscat
+.TP
+.B C-Sky
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+ck610,
+ck807,
+ck810,
+ck860
 .TP
 .B MIPS
-loongson2e, loongson2f, octeon, octeon2
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+loongson2e,
+loongson2f,
+octeon,
+octeon2
 .TP
 .B PowerPC
-4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle,
-fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601,
-ppc64, smt, spe, ucache, vsx
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+4xxmac,
+altivec,
+arch_2_05,
+arch_2_06,
+arch_2_07,
+arch_3_00,
+archpmu,
+booke,
+cellbe,
+darn,
+dfp,
+dscr,
+ebb,
+efpdouble,
+efpsingle,
+fpu,
+htm,
+htm-nosc,
+htm-no-suspend,
+ic_snoop,
+ieee128,
+isel,
+mmu,
+notb,
+pa6t,
+power4,
+power5,
+power5+,
+power6x,
+ppc32,
+ppc601,
+ppc64,
+ppcle,
+scv,
+smt,
+spe,
+tar,
+true_le,
+ucache,
+vcrypto,
+vsx
 .TP
 .B SPARC
-flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+ASIBlkInit,
+adp,
+cbcond,
+crypto,
+cspare,
+div32,
+fjfmau,
+flush,
+fmaf,
+fsmuld,
+hpc,
+ima,
+muldiv,
+mul32,
+pause,
+popc,
+random,
+stbar,
+swap,
+trans,
+ultra3,
+v8plus,
+vis,
+vis2,
+vis3,
+v9,
+v9v,
+v9v2
 .TP
 .B s390
-dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle,
-z900, z990, z9-109, z10, zarch
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - etf3enh and hpage deprecated in glibc 2.17 by commit
+.\"   0ab234b7db4991121eb572bf5c4971bfeb2d49a2.
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+dflt,
+dfp,
+edat,
+eimm,
+esan3,
+etf3eh,
+etf3enh (removed in glibc 2.17),
+g5,
+gs,
+highgprs,
+hpage (removed in glibc 2.17),
+ldisp,
+msa,
+sort,
+stfle,
+te,
+vx,
+vxd,
+vxe,
+vxe2,
+vxp,
+z10,
+z13,
+z14,
+z15,
+z196,
+z900,
+z9-109,
+z990,
+zarch,
+zEC12
 .TP
 .B x86 (32-bit only)
-acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx,
-mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - i386 and i486 deprecated in glibc 2.26 by commit
+.\"   1432d38ea04ab5e96f21a382101856db5b49ad8a
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+10,
+20,
+acpi,
+apic,
+clflush,
+cmov,
+cx8,
+de,
+dts,
+fpu,
+fxsr,
+ht,
+i386 (removed in glibc 2.26),
+i486 (removed in glibc 2.26),
+i586,
+i686,
+mca,
+mce,
+mmx,
+msr,
+mtrr,
+pae,
+pat,
+pbe,
+pge,
+pn,
+pse,
+pse36,
+sep,
+ss,
+sse,
+sse2,
+tm,
+tsc,
+vme
+.TP
+.B x86 (64-bit only)
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - Added haswell, and xeon-phi in glibc 2.26 with commit
+.\"   1432d38ea04ab5e96f21a382101856db5b49ad8a
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+avx512_1,
+haswell (since glibc 2.26),
+sse2,
+x86_64,
+xeon-phi (since glibc 2.26),
 .SH SEE ALSO
 .BR ld (1),
 .BR ldd (1),
-- 
2.26.2

Re: [PATCH] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Florian Weimer]

* Carlos O'Donell:

> +The following names are currently recognized as of the release of glibc 2.31:
> +.\" This information comes from glibc's sysdeps/*/dl-procinfo.c and is
> +.\" currently not directly documented in the glibc manual. We document
> +.\" it here with the help of the glibc maintainers.

I'm not sure if this list is correct.  Did you filter the hwcap strings
based on HWCAP_IMPORTANT?

Thanks,
Florian

Re: [PATCH] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Carlos O'Donell]

On 5/28/20 5:35 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> +The following names are currently recognized as of the release of glibc 2.31:
>> +.\" This information comes from glibc's sysdeps/*/dl-procinfo.c and is
>> +.\" currently not directly documented in the glibc manual. We document
>> +.\" it here with the help of the glibc maintainers.
> 
> I'm not sure if this list is correct.  Did you filter the hwcap strings
> based on HWCAP_IMPORTANT?

Oh good point, I forgot that some arches use _dl_string_hwcap() and other
arches use _dl_string_platform().

Let me filter these quickly based on the selection, and add some more comments
with the appropriate notes.

Wait for v2.

-- 
Cheers,
Carlos.

[PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Carlos O'Donell]

On 5/28/20 5:35 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> +The following names are currently recognized as of the release of glibc 2.31:
>> +.\" This information comes from glibc's sysdeps/*/dl-procinfo.c and is
>> +.\" currently not directly documented in the glibc manual. We document
>> +.\" it here with the help of the glibc maintainers.
> 
> I'm not sure if this list is correct.  Did you filter the hwcap strings
> based on HWCAP_IMPORTANT?

This turned out to be much harder than expected. Here is the updated
list with all the filtering documented.

v2
- For each arch checked against 

8< --- 8< --- 8<
The "Hardware capabilities" section is seeing an update in upstream
glibc as we review how the search directories are handled between
the various architectures. In the meantime we should update the man
page to reflect the current set of search paths for all supported
target machines.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>
---
 man8/ld.so.8 | 179 +++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 161 insertions(+), 18 deletions(-)

diff --git a/man8/ld.so.8 b/man8/ld.so.8
index f34eca3d8..3dbb34a23 100644
--- a/man8/ld.so.8
+++ b/man8/ld.so.8
@@ -746,36 +746,179 @@ Some shared objects are compiled using hardware-specific instructions which do
 not exist on every CPU.
 Such objects should be installed in directories whose names define the
 required hardware capabilities, such as
-.IR /usr/lib/sse2/ .
-The dynamic linker checks these directories against the hardware of the
-machine and selects the most suitable version of a given shared object.
-Hardware capability directories can be cascaded to combine CPU features.
-The list of supported hardware capability names depends on the CPU.
-The following names are currently recognized:
-.\" Presumably, this info comes from sysdeps/i386/dl-procinfo.c and
-.\" similar files
+.IR /usr/lib64/haswell/ .
+The dynamic linker checks these directories against the hardware of the machine
+and selects the most suitable version of a given shared object.  Hardware
+capability directories can be cascaded to combine CPU features.  The list of
+supported hardware capability names depends on the CPU.  The list of supported
+hardware capability names may change with each release of the C library and is
+considered an optimization, and should not be relied upon for correct operation
+of the application. Applications should provide a default non-optimized
+implementation that is installed in the default library search paths.
+Care should be taken when packaging such application with a package manager,
+particularly the scenario where an optimized library is being removed.  With
+certain package managers, particularly rpm, the newer version of the
+application is installed first, which means that for a period of time during
+the upgrade all applications that use the library may start with a mixed set of
+libraries e.g.  the old library from the feature-based search path, and new
+libraries from the upgrade. To avoid this scenario the new library version
+should delete all known optimized libraries in the post-install phase.
+.TP
+The following names are currently recognized as of the release of glibc 2.31:
+.\" This information comes from glibc's sysdeps/*/dl-procinfo.c and
+.\" sysdeps/*/dl-procinfo.h and is currently not directly documented in the
+.\" glibc manual. The analysis is non-trivial and requires some filtering
+.\" via _dl_string_platform(), _dl_string_hwcap() and HWCAP_IMPORTANT.
+.\" We document it here with the help of the glibc maintainers.
 .TP
 .B Alpha
-ev4, ev5, ev56, ev6, ev67
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_platform() from GLRO(dl_alpha_platforms).
+ev4,
+ev5,
+ev56,
+ev6,
+ev67
+.TP
+.B Arm AArch32
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_hwcap() from GLRO(dl_arm_cap_flags)
+.\"   which uses HWCAP_IMPORTANT to limit the list to vfp and neon.
+neon,
+vfp
+.TP
+.B Arm AArch64
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_hwcap() from GLRO(dl_aarch64_cap_flags)
+.\"   which uses HWCAP_IMPORTANT to limit the list to atomics.
+atomics
+.TP
+.B C-Sky
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_platform() from GLRO(dl_csky_platforms).
+ck610,
+ck807,
+ck810,
+ck860
 .TP
 .B MIPS
-loongson2e, loongson2f, octeon, octeon2
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_platform() from GLRO(dl_mips_platforms).
+loongson2e,
+loongson2f,
+octeon,
+octeon2
 .TP
 .B PowerPC
-4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle,
-fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601,
-ppc64, smt, spe, ucache, vsx
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_hwcap() from GLRO(dl_powerpc_cap_flags)
+.\"   which uses HWCAP_IMPORTANT to limit the list to altivec and dfp.
+.\" - Additional list exposed via _dl_string_platform() from a programmatic
+.\"   construction of power architecutre names (requires reading the code).
+altivec,
+dfp,
+power4,
+power5,
+power5+,
+power6,
+power6x,
+power7,
+power8,
+power9,
+ppc970,
+ppc-cell-be,
+ppca2,
+ppc405,
+ppc440,
+ppc464,
+ppc476
 .TP
 .B SPARC
-flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_hwcap() from GLRO(dl_sparc_cap_flags)
+.\"   which uses HWCAP_IMPORTANT to limit the list to v9, ultra3,
+.\"   v9v (HWCAP_SPARC_BLKINIT), and v9v2 (HWCAP_SPARC_N2).
+ultra3,
+v9 (32-bit only),
+v9v,
+v9v2
 .TP
 .B s390
-dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle,
-z900, z990, z9-109, z10, zarch
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - etf3enh and hpage deprecated in glibc 2.17 by commit
+.\"   0ab234b7db4991121eb572bf5c4971bfeb2d49a2.
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List exposed via _dl_string_hwcap() from GLRO(dl_s390_cap_flags)
+.\"   which uses HWCAP_IMPORTANT to limit the list to zarch, ldisp,
+.\"   eimm, dfp, vx, vxe, and vxe2.
+.\" - Additional list exposed via _dl_string_platform() from
+.\"   GLRO(dl_s390_platforms). 
+dfp,
+eimm,
+g5,
+ldisp,
+vx,
+vxe,
+vxe2,
+z10,
+z13,
+z14,
+z15,
+z196,
+z900,
+z9-109,
+z990,
+zarch,
+zEC12
 .TP
 .B x86 (32-bit only)
-acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx,
-mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - i386 and i486 deprecated in glibc 2.26 by commit
+.\"   1432d38ea04ab5e96f21a382101856db5b49ad8a
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List is exposed via _dl_string_hwcap() from GLRO(dl_x86_hwcap_flags)
+.\"   and uses HWCAP_IMPORTANT to limit the list to sse2. 
+.\"   - Defined in sysdeps/x86/dl-hwcap.h (not the normal place for this).
+.\" - Additional list exposed via _dl_string_platform() from
+.\"   GLRO(dl_x86_platforms) and filtered via HWCAP_PLATFORMS_START and
+.\"   HWCAP_PLATFORMS_COUNT.
+sse2,
+i386 (removed in glibc 2.26),
+i486 (removed in glibc 2.26),
+i586,
+i686
+.TP
+.B x86 (64-bit only)
+.\" One item per line to allow comparison with source specification.
+.\" Notes:
+.\" - Added haswell, and xeon-phi in glibc 2.26 with commit
+.\"   1432d38ea04ab5e96f21a382101856db5b49ad8a
+.\" - List current as of commit 38c67888183db1b6ac21f2f9681b8a384987dfe8.
+.\" - List is exposed via _dl_string_hwcap() from GLRO(dl_x86_hwcap_flags) 
+.\"   and uses HWCAP_IMPORTANT to limit the list to x86_64 and avx512_1.
+.\" - Additional list exposed via _dl_string_platform() from
+.\"   GLRO(dl_x86_platforms) and filtered via HWCAP_PLATFORMS_START and
+.\"   HWCAP_PLATFORMS_COUNT.
+x86_64,
+avx512_1,
+haswell (since glibc 2.26),
+xeon-phi (since glibc 2.26)
 .SH SEE ALSO
 .BR ld (1),
 .BR ldd (1),
-- 
2.26.2

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Florian Weimer]

* Carlos O'Donell:

> +Care should be taken when packaging such application with a package manager,
> +particularly the scenario where an optimized library is being removed.  With
> +certain package managers, particularly rpm, the newer version of the

Twice “particularly”.

> +application is installed first, which means that for a period of time during
> +the upgrade all applications that use the library may start with a mixed set of
> +libraries e.g.  the old library from the feature-based search path, and new

Commas arount e.g.?

> +libraries from the upgrade. To avoid this scenario the new library version
> +should delete all known optimized libraries in the post-install phase.

There is a different mechanism: Debian has patched glibc to disable
hwcap subdirectors if the file /etc/ld.so.nohwcap exists.

You now list the AT_PLATFORM directories (determined by the kernel on
most architectures) along the regular hwcaps directories, although they
are handled somewhat differently.  For example, on s390x, if you have a
“z15” machine (as indicated by AT_PLATFORM), the “z13” subdirectory is
not selected.  ldconfig will add it to the cache, but it will not be
used at run time.  I'm not sure if your proposed description gives
readers the right idea what happens.

Thanks,
Florian

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Michael Kerrisk (man-pages)]

Hi Carlos,

What's the status of this patch?

Thanks,

Michael


On Tue, 2 Jun 2020 at 08:14, Florian Weimer <fweimer@redhat.com> wrote:
>
> * Carlos O'Donell:
>
> > +Care should be taken when packaging such application with a package manager,
> > +particularly the scenario where an optimized library is being removed.  With
> > +certain package managers, particularly rpm, the newer version of the
>
> Twice “particularly”.
>
> > +application is installed first, which means that for a period of time during
> > +the upgrade all applications that use the library may start with a mixed set of
> > +libraries e.g.  the old library from the feature-based search path, and new
>
> Commas arount e.g.?
>
> > +libraries from the upgrade. To avoid this scenario the new library version
> > +should delete all known optimized libraries in the post-install phase.
>
> There is a different mechanism: Debian has patched glibc to disable
> hwcap subdirectors if the file /etc/ld.so.nohwcap exists.
>
> You now list the AT_PLATFORM directories (determined by the kernel on
> most architectures) along the regular hwcaps directories, although they
> are handled somewhat differently.  For example, on s390x, if you have a
> “z15” machine (as indicated by AT_PLATFORM), the “z13” subdirectory is
> not selected.  ldconfig will add it to the cache, but it will not be
> used at run time.  I'm not sure if your proposed description gives
> readers the right idea what happens.
>
> Thanks,
> Florian
>


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Carlos O'Donell]

On 6/10/20 2:00 AM, Michael Kerrisk (man-pages) wrote:
> Hi Carlos,
> 
> What's the status of this patch?

I'm currently rewriting the language of the section to split apart the
AT_PLATFORM and AT_HWCAP parts.

They each behave differently. AT_PLATFORM is a non-nested singular platform
directory that is searched with no fallback, and that needs to clarified
and called out. While AT_HWCAP is drastically different in behaviour.

When done we'll have two lists, and two explanations for the search paths
and their orders.

I'm doing this as part of the upstream review of this infrasturcture
because we're going to change the behaviour in an upcoming release. With
the changes in place we'll have a good place to say "... and now it's different."

In summary: Still working on it. Expect v3.

> On Tue, 2 Jun 2020 at 08:14, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Carlos O'Donell:
>>
>>> +Care should be taken when packaging such application with a package manager,
>>> +particularly the scenario where an optimized library is being removed.  With
>>> +certain package managers, particularly rpm, the newer version of the
>>
>> Twice “particularly”.
>>
>>> +application is installed first, which means that for a period of time during
>>> +the upgrade all applications that use the library may start with a mixed set of
>>> +libraries e.g.  the old library from the feature-based search path, and new
>>
>> Commas arount e.g.?
>>
>>> +libraries from the upgrade. To avoid this scenario the new library version
>>> +should delete all known optimized libraries in the post-install phase.
>>
>> There is a different mechanism: Debian has patched glibc to disable
>> hwcap subdirectors if the file /etc/ld.so.nohwcap exists.
>>
>> You now list the AT_PLATFORM directories (determined by the kernel on
>> most architectures) along the regular hwcaps directories, although they
>> are handled somewhat differently.  For example, on s390x, if you have a
>> “z15” machine (as indicated by AT_PLATFORM), the “z13” subdirectory is
>> not selected.  ldconfig will add it to the cache, but it will not be
>> used at run time.  I'm not sure if your proposed description gives
>> readers the right idea what happens.
>>
>> Thanks,
>> Florian
>>
> 
> 
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> 


-- 
Cheers,
Carlos.

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Florian Weimer]

* Carlos O'Donell:

> On 6/10/20 2:00 AM, Michael Kerrisk (man-pages) wrote:
>> Hi Carlos,
>> 
>> What's the status of this patch?
>
> I'm currently rewriting the language of the section to split apart the
> AT_PLATFORM and AT_HWCAP parts.
>
> They each behave differently. AT_PLATFORM is a non-nested singular platform
> directory that is searched with no fallback, and that needs to clarified
> and called out. While AT_HWCAP is drastically different in behaviour.

I think AT_PLATFORM behaves like any of the AT_HWCAP directories, except
that the name is determined by information from the kernel.

Thanks,
Florian

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Florian Weimer]

* Carlos O'Donell:

> On 6/10/20 2:00 AM, Michael Kerrisk (man-pages) wrote:
>> Hi Carlos,
>> 
>> What's the status of this patch?
>
> I'm currently rewriting the language of the section to split apart the
> AT_PLATFORM and AT_HWCAP parts.
>
> They each behave differently. AT_PLATFORM is a non-nested singular platform
> directory that is searched with no fallback, and that needs to clarified
> and called out. While AT_HWCAP is drastically different in behaviour.
>
> When done we'll have two lists, and two explanations for the search paths
> and their orders.
>
> I'm doing this as part of the upstream review of this infrasturcture
> because we're going to change the behaviour in an upcoming release. With
> the changes in place we'll have a good place to say "... and now it's different."
>
> In summary: Still working on it. Expect v3.

Carlos, what's the status here?  I need to write an update for
glibc-hwcaps, and this likely conflicts with your edits (at least
semantically).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Re: [PATCH v2] ld.so.8: Update "Hardware capabilities" section for glibc 2.31.

[Carlos O'Donell]

On 12/4/20 4:12 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 6/10/20 2:00 AM, Michael Kerrisk (man-pages) wrote:
>>> Hi Carlos,
>>>
>>> What's the status of this patch?
>>
>> I'm currently rewriting the language of the section to split apart the
>> AT_PLATFORM and AT_HWCAP parts.
>>
>> They each behave differently. AT_PLATFORM is a non-nested singular platform
>> directory that is searched with no fallback, and that needs to clarified
>> and called out. While AT_HWCAP is drastically different in behaviour.
>>
>> When done we'll have two lists, and two explanations for the search paths
>> and their orders.
>>
>> I'm doing this as part of the upstream review of this infrasturcture
>> because we're going to change the behaviour in an upcoming release. With
>> the changes in place we'll have a good place to say "... and now it's different."
>>
>> In summary: Still working on it. Expect v3.
> 
> Carlos, what's the status here?  I need to write an update for
> glibc-hwcaps, and this likely conflicts with your edits (at least
> semantically).

I won't be able to touch this until the new year. I want to handle the
higher priority glibc patches for review.

Please feel free to rewrite, change, and do whatever you want.

-- 
Cheers,
Carlos.