Le jeudi 13 août 2026, 13:43:46 heure d’été d’Europe centrale Simon McVittie a écrit : > On Thu, 13 Aug 2026 at 13:00:41 +0200, John Paul Adrian Glaubitz wrote: > >On Thu, 2026-08-13 at 12:53 +0200, Bastien Roucaries wrote: > >> In order to ease the user/devel experience I want for isa-support to > >> create test for forky baseline > >> > >> For now I test for armhf: > >> > >> armv8-support > >> CPU feature checking - require ARMv8 > >> > >> neon-support > > > >Not sure I understand this. You want to raise armhf to ARMv8? Why would > >anyone then install a 32-bit port when they could just use the 64-bit > >port in the first place? > > I think perhaps what Bastien is trying to do is to identify useful > functionality levels that are *above* the baseline, so that isa-support > can be used to gate their availability; while avoiding checks for > functionality levels that are *below* the baseline, because by > definition Debian is not expected to run on CPUs that lack that > functionality anyway?
Yes it is is > > The purpose of isa-support is that when our official architecture > baseline is relatively low (like i586 on bookworm i386), but a specific > package needs a higher functionality level (like various i386 packages > that needed SSE2 anyway), those specific packages can depend on > something like > > sse2-support [i386] > > and the result will be that the package fails to install on baseline > CPUs, and only installs successfully on those CPUs where it can actually > work. You could even now test at run time using isa-support package and /usr/libexec/x86_64-linux-gnu/isa-support/test-SSE3 /usr/libexec/x86_64-linux-gnu/isa-support/test-SSE4.1 /usr/libexec/x86_64-linux-gnu/isa-support/test-SSE4.2 /usr/libexec/x86_64-linux-gnu/isa-support/test-x86-64-v2 /usr/libexec/x86_64-linux-gnu/isa-support/test-x86-64-v3 qemu command are available in case of problem: /usr/libexec/x86_64-linux-gnu/isa-support/qemu-bad-SSE3 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-bad-SSE4.1 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-bad-SSE4.2 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-bad-x86-64-v2 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-bad-x86-64-v3 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-good-SSE3 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-good-SSE4.1 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-good-SSE4.2 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-good-x86-64-v2 /usr/libexec/x86_64-linux-gnu/isa-support/qemu-good-x86-64-v3 run it with program and you could check if program run with or without extra instruction. > > Since trixie, we officially require more i386 features than we did in > bookworm[1] so the common case of needing SSE2 is no longer interesting: > all of our x86 CPUs are meant to have SSE2 anyway. But I expect that > we'll see analogous situations appear for higher CPU functionality > levels: there's already some x86 binary software that requires higher > than x86-64-v1. For example, Steam requires SSE3 and CMPXCHG8, which are > x86-64-v2 features. > > [1] > https://www.debian.org/releases/trixie/release-notes/issues.en.html#reduced-support-for-i386 > > The use case for armv8-support on armhf would be a piece of software > that has to be compiled as 32-bit for ABI compatibility reasons, but > requires ARMv8 CPU functionality, and therefore has: > > Depends armv8-support [armhf] > > Bastien, are you aware of any specific pieces of software on armhf that > have this requirement, or are you adding a check and a package > speculatively in case a package needs it in future? I suppose JIT program nodejs was complicated, chromium also. > On x86, there's a > lot of legacy binary-only software that requires 32-bit libraries to > continue to exist on x86_64 (mostly games), but I wasn't aware that > armhf had a similar legacy binary requirement (and if it does, we'll > have broken a lot of it anyway, by doing the 64-bit time_t transition). > > >> For amd64/i386 (i will like to only use psABI defintion so > >> > >> sse3-support > >> vérification de caractéristique de CPU – besoin de SSE3 > >> sse4.1-support > >> CPU feature checking - require SSE4.1 > >> sse4.2-support > >> SSE4.2 > >> x86-64-v2-support > >> CPU feature checking - require x86-64-v2 > >> x86-64-v3-support > >> CPU feature checking - require x86-64-v3 > > > >Isn't that something that should be done using hwcaps support? > > You can use hwcaps or a similar mechanism for libraries, for example if > your use-case is that you have a less-optimized version of OpenSSL > compiled for the x86_64 baseline, and a more-optimized version compiled > with x86-64-v2 requirements that can be used to speed up systems with a > better CPU. As long as the ABI is the same, the better/faster library > can be a drop-in substitute for the less-optimized one. > > But, using hwcaps isn't necessarily feasible if a whole program or > component makes higher-than-baseline assumptions. For example Steam is > known to require SSE3 and CMPXCHG16B, which are higher than the > x86_64-v1 baseline (they're a subset of x86-64-v2); and I could easily > imagine Chromium or Firefox deciding that its x86_64 JIT implementation > is going to assume non-baseline CPU features to improve performance or > code complexity. For sse3 Reverse Depends: libhyperscan5 (5.4.2-3) Reverse Depends: libqt6webenginecore6 (6.8.2+dfsg-4) > > (Steam as packaged in Debian as steam-installer doesn't currently use > isa-support, but the upstream code has a check for the required CPU > features and an error message popup if they are missing. A dependency on > sse3-support would probably make sense, I'll add that at some point.) > > Sometimes the use of these newer CPU features is a pervasive > architectural assumption, rather than something you can turn on and off. > For example, I don't know for sure why Steam needs CMPXCHG16B (128-bit > atomic operations), but it's probably safe to assume that it's using > them for some sort of lockless synchronization between threads or > processes. If it's that, then its developers are unlikely to be willing > to write a baseline-compatible fallback - and after committing to using > 128-bit atomic ops, it might not be *possible* to write a fallback without > breaking compatibility, even if they wanted to. > > >> for ppc/ppc64 > >> > >> altivec-support > > > >POWER8 already has AltiVec. For powerpc and ppc64, AltiVec is not > >required in the baseline because there are some embedded systems > >that people use that don't support AltiVec despite being more recent > >than some of the first AltiVec CPUs. > > Right, that makes this a good example of where isa-support is useful. > The purpose of having an altivec-support package in isa-support would be > so that Debian-as-a-whole can continue to be installable on those > embedded CPUs, but when a specific piece of software *does* require > Altivec (like ioquake3 did in the past), that piece of software can be > installable onto POWER8 and Apple G4/G5 systems, but flagged as not > suitable for the embedded CPUs that you mentioned. > > smcv > >
signature.asc
Description: This is a digitally signed message part.
