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?
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.
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? 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.
(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
