Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #89777 > unrolled thread

Architecture baseline for Forky

Back to article view | Back to linux.debian.kernel

Contents

  Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-26 13:40 +0100
    Re: Architecture baseline for Forky John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-10-26 14:20 +0100
      Re: Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-27 08:40 +0100
    Re: Architecture baseline for Forky Tony Rodriguez <unixpro1970@gmail.com> - 2025-10-26 19:40 +0100
      Re: Architecture baseline for Forky John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2025-10-26 20:30 +0100
      Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-27 12:50 +0100
        Re: Architecture baseline for Forky Martin <debacle@debian.org> - 2025-10-27 18:10 +0100
        Re: Architecture baseline for Forky "Arnd Bergmann" <arnd@arndb.de> - 2025-10-27 22:40 +0100
          Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-29 09:00 +0100
            Re: Architecture baseline for Forky Peter Green <plugwash@debian.org> - 2025-10-30 07:00 +0100
              Re: Architecture baseline for Forky Peter Green <plugwash@debian.org> - 2025-10-30 10:10 +0100
                Re: Architecture baseline for Forky "Arnd Bergmann" <arnd@arndb.de> - 2025-10-30 10:10 +0100
            Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-30 15:30 +0100
      Re: Architecture baseline for Forky Rob Landley <rob@landley.net> - 2025-10-27 21:40 +0100
    Re: Architecture baseline for Forky Adrian Bunk <bunk@debian.org> - 2025-10-27 11:20 +0100
    Re: Architecture baseline for Forky Colin Watson <cjwatson@debian.org> - 2025-10-27 19:30 +0100
      Re: Architecture baseline for Forky "Nikos Tsipinakis" <nikos@tsipinakis.com> - 2025-10-30 14:40 +0100
    Re: Architecture baseline for Forky Milan Kupcevic <milan@debian.org> - 2025-10-27 22:40 +0100
      Re: Architecture baseline for Forky Bastian Blank <waldi@debian.org> - 2025-10-27 23:40 +0100
        Re: Architecture baseline for Forky Marc Haber <mh+debian-release@zugschlus.de> - 2025-10-28 10:10 +0100
      Planned obsolescence ? (was: Re: Architecture baseline for Forky) Romain Dolbeau <romain@dolbeau.org> - 2025-10-28 10:00 +0100
        Re: Planned obsolescence ? (OpenBSD) Paul Tagliamonte <paultag@debian.org> - 2025-11-02 23:30 +0100
        Re: Planned obsolescence ? (*BSD, Rust) David Starner <prosfilaes@gmail.com> - 2025-11-04 00:20 +0100
    Re: Architecture baseline for Forky Rob Landley <rob@landley.net> - 2025-12-05 00:20 +0100
    R: Re: Architecture baseline for Forky Federico Vaga <federico.vaga@vaga.pv.it> - 2026-09-07 09:20 +0200

Page 1 of 2  [1] 2  Next page →

#89777 — Architecture baseline for Forky

Hi

We never did a real discussion about architecture baselines before, but I think
we should do that.  We also don't have any guidelines what we as Debian want to
actually support.  But given that we are a general purpose distribution, we
have to find a balance.

As a general guidance I would like to aim for a ten to 15 years support range
at release time.  The cutoff in respect to the expected 2027 release date of
Forky would therefor be 2012 to 2017.  More time is given for widely used
architectures, less for more specialized ones.

Bastian

# Current architecture baseline

Only three architectures set an explicit baseline in gcc-12 (Bookworm) and
gcc-15 (Forky):
* armhf: armv7-a+fp
* i386: i686
* s390: z196

All other architectures use the default values.

# Proposal for architecture baseline

## amd64 (and i386)

* x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9x86].
* x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
  10[^redhat10].

I propose to use the x86-64-v2 baseline in Forky.  It gives us more then the 15
years and everyone else already switched to it or even a newer variant.
Factoring in a possible LTS for Trixie, this means that x86-64-v1 will stop
being supported by Debian in 2030.

## ppc64el

* POWER8: Launched in 2014[^power8].
* POWER9: Launched in 2017[^power9]. Used in RedHat 9[^redhat9] and
  10[^redhat10].

I propose to use the POWER9 baseline in Forky.  The Debian infrastructure seems
to be comprised of all POWER9s.  This means POWER8 will stop being supported in
2028.

## s390x

* z14: Launched in 2017[^z14]. Used by RedHat 10[^redhat10].
* z15: Launched in 2019[^z15]. Used by next Ubuntu.

I propose to use the z15 baseline in Forky.  Yes, this is less then ten years,
but s390 is such a niche architecture and all we do is best (often not even
this) effort support.  The Debian infrastructure is documented to be at least
z15, all accesible system are actually z16.  This means that z14 and older will
stop being support in 2028.

# How to see supported baseline

The dynamic linker of glibc can show what microarchiture level it considers
supported on the current CPU.  The "supported" marker is relevant in this case.

## amd64
```
% /usr/lib64/ld-linux-x86-64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)
```

## ppc64el
```
% /usr/lib64/ld64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'          
Subdirectories of glibc-hwcaps directories, in priority order:
  power10
  power9 (supported, searched)
```

## s390x
```
% /usr/lib/ld64.so.1 --help | sed -n '/^Subdirectories of glibc-hwcaps/,/^  z15/p'           
Subdirectories of glibc-hwcaps directories, in priority order:
  z16 (supported, searched)
  z15 (supported, searched)
```

[^power8]: https://en.wikipedia.org/wiki/POWER8
[^power9]: https://en.wikipedia.org/wiki/POWER9
[^x86]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
[^z14]: https://en.wikipedia.org/wiki/IBM_z14_(microprocessor)
[^z15]: https://en.wikipedia.org/wiki/IBM_z15_(microprocessor)
[^redhat9]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.0_release_notes/architectures
[^redhat9x86]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
[^redhat10]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/considerations_in_adopting_rhel_10/architectures

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

[toc] | [next] | [standalone]

#89779

Hi Bastian,

On Sun, 2025-10-26 at 13:21 +0100, Bastian Blank wrote:
> All other architectures use the default values.

What about riscv64, is that going to make the same switch as Ubuntu (RV23)?

And any plans for loong64 yet? The port is very mature these days and we have
two beefy loong64 machines under the supervision of DSA. It's a very good
candidate for forky in my opinion.

> ## ppc64el
> 
> * POWER8: Launched in 2014[^power8].
> * POWER9: Launched in 2017[^power9]. Used in RedHat 9[^redhat9] and
>   10[^redhat10].
> 
> I propose to use the POWER9 baseline in Forky.  The Debian infrastructure seems
> to be comprised of all POWER9s.  This means POWER8 will stop being supported in
> 2028.

I think dropping POWER8 is a bit early given that POWER9 is just three years younger.

> ## s390x
> 
> * z14: Launched in 2017[^z14]. Used by RedHat 10[^redhat10].
> * z15: Launched in 2019[^z15]. Used by next Ubuntu.
> 
> I propose to use the z15 baseline in Forky.  Yes, this is less then ten years,
> but s390 is such a niche architecture and all we do is best (often not even
> this) effort support.  The Debian infrastructure is documented to be at least
> z15, all accesible system are actually z16.  This means that z14 and older will
> stop being support in 2028.

Do we have any sort of feedback what machines users run Debian's s390x port on?

I would argue that both POWER and z-Series are hardware with very long support
cycles by the manufacturer, so I think the baselines should be moved at a slower
pace compared to x86_64 where acquiring new hardware also doesn't cost a fortune.

Thanks,
Adrian


-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#89785

Okay, lists does not want my emails anymore…

On Sun, Oct 26, 2025 at 02:17:58PM +0100, John Paul Adrian Glaubitz wrote:
> On Sun, 2025-10-26 at 13:21 +0100, Bastian Blank wrote:
> > All other architectures use the default values.
> What about riscv64, is that going to make the same switch as Ubuntu (RV23)?

I did not formulate a plan for riscv64.  RV23 also does not seem to be
finished yet (the required V extension seems to be not final yet).  Nor
does Debian got hardware that would work with it.

> And any plans for loong64 yet? The port is very mature these days and we have
> two beefy loong64 machines under the supervision of DSA. It's a very good
> candidate for forky in my opinion.

This is a new architecture, so unrelated to this.

> > I propose to use the POWER9 baseline in Forky.  The Debian infrastructure seems
> > to be comprised of all POWER9s.  This means POWER8 will stop being supported in
> > 2028.
> I think dropping POWER8 is a bit early given that POWER9 is just three years younger.

POWER9 is actually a large update of the instruction set.  It includes a
redesigned vector unit, while POWER8 needs some achrobatics to use
vector stuff in little endian mode.  Also it brings 128bit floating
point.

> > I propose to use the z15 baseline in Forky.
> Do we have any sort of feedback what machines users run Debian's s390x port on?

No we don't.

> I would argue that both POWER and z-Series are hardware with very long support
> cycles by the manufacturer

Actually they are not.  z13 is end of service since end of last year.
If they follow the same pattern, all z14 variants will be end of service
at the end of 2026.  And users of that hardware are way less likely to
use it without service and you won't find them in the homes of
enthusiasts.

POWER8 is also end of service since last year.  More likely to show up,
yes.

Bastian

-- 
You can't evaluate a man by logic alone.
		-- McCoy, "I, Mudd", stardate 4513.3

[toc] | [prev] | [next] | [standalone]

#89780

Why not support power 8 beyond 2028? It is still a good system and supports newer little endian. Hopefully, you can reconsider and keep power 8 for as long as power 9/10 regarding baseline support.

> On Oct 26, 2025, at 5:40 AM, Bastian Blank <waldi@debian.org> wrote:
> 
> Hi
> 
> We never did a real discussion about architecture baselines before, but I think
> we should do that.  We also don't have any guidelines what we as Debian want to
> actually support.  But given that we are a general purpose distribution, we
> have to find a balance.
> 
> As a general guidance I would like to aim for a ten to 15 years support range
> at release time.  The cutoff in respect to the expected 2027 release date of
> Forky would therefor be 2012 to 2017.  More time is given for widely used
> architectures, less for more specialized ones.
> 
> Bastian
> 
> # Current architecture baseline
> 
> Only three architectures set an explicit baseline in gcc-12 (Bookworm) and
> gcc-15 (Forky):
> * armhf: armv7-a+fp
> * i386: i686
> * s390: z196
> 
> All other architectures use the default values.
> 
> # Proposal for architecture baseline
> 
> ## amd64 (and i386)
> 
> * x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9x86].
> * x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
>  10[^redhat10].
> 
> I propose to use the x86-64-v2 baseline in Forky.  It gives us more then the 15
> years and everyone else already switched to it or even a newer variant.
> Factoring in a possible LTS for Trixie, this means that x86-64-v1 will stop
> being supported by Debian in 2030.
> 
> ## ppc64el
> 
> * POWER8: Launched in 2014[^power8].
> * POWER9: Launched in 2017[^power9]. Used in RedHat 9[^redhat9] and
>  10[^redhat10].
> 
> I propose to use the POWER9 baseline in Forky.  The Debian infrastructure seems
> to be comprised of all POWER9s.  This means POWER8 will stop being supported in
> 2028.
> 
> ## s390x
> 
> * z14: Launched in 2017[^z14]. Used by RedHat 10[^redhat10].
> * z15: Launched in 2019[^z15]. Used by next Ubuntu.
> 
> I propose to use the z15 baseline in Forky.  Yes, this is less then ten years,
> but s390 is such a niche architecture and all we do is best (often not even
> this) effort support.  The Debian infrastructure is documented to be at least
> z15, all accesible system are actually z16.  This means that z14 and older will
> stop being support in 2028.
> 
> # How to see supported baseline
> 
> The dynamic linker of glibc can show what microarchiture level it considers
> supported on the current CPU.  The "supported" marker is relevant in this case.
> 
> ## amd64
> ```
> % /usr/lib64/ld-linux-x86-64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'
> Subdirectories of glibc-hwcaps directories, in priority order:
>  x86-64-v4
>  x86-64-v3 (supported, searched)
>  x86-64-v2 (supported, searched)
> ```
> 
> ## ppc64el
> ```
> % /usr/lib64/ld64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'          
> Subdirectories of glibc-hwcaps directories, in priority order:
>  power10
>  power9 (supported, searched)
> ```
> 
> ## s390x
> ```
> % /usr/lib/ld64.so.1 --help | sed -n '/^Subdirectories of glibc-hwcaps/,/^  z15/p'           
> Subdirectories of glibc-hwcaps directories, in priority order:
>  z16 (supported, searched)
>  z15 (supported, searched)
> ```
> 
> [^power8]: https://en.wikipedia.org/wiki/POWER8
> [^power9]: https://en.wikipedia.org/wiki/POWER9
> [^x86]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
> [^z14]: https://en.wikipedia.org/wiki/IBM_z14_(microprocessor)
> [^z15]: https://en.wikipedia.org/wiki/IBM_z15_(microprocessor)
> [^redhat9]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.0_release_notes/architectures
> [^redhat9x86]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> [^redhat10]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/considerations_in_adopting_rhel_10/architectures
> 
> --
> Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
> 

[toc] | [prev] | [next] | [standalone]

#89781

On Sun, 2025-10-26 at 20:12 +0100, Marco d'Itri wrote:
> On Oct 26, Tony Rodriguez <unixpro1970@gmail.com> wrote:
> 
> > Why not support power 8 beyond 2028? It is still a good system and 
> > supports newer little endian.
> 
> Because that's 15 years and Debian's purpose is not to enable 
> retrocomputing projects.

I don't think that POWER8 would be considered retrocomputing given the fact
that it's just three years older than POWER9. The first x86_64 CPUs were
released in 2003 and are still supported by Debian.

If hardware released between 2014 and 2022 (last POWER8 server sold is considered
retro, then the original x86_64 hardware would be considered ancient, wouldn't it?

While POWER8 hardware reached EOL at IBM last year, I don't think this should be
decisive criteria. You can also argue that quickly raising baselines will cause
more e-waste.

> I think that waldi's proposal is quite reasonable.
> 
> Next year probably we should also talk about RISC-V, when hopefully it 
> will be more clear what hardware will be available.

Well, Ubuntu raised the baseline to RV23 before there was even any hardware available
meaning that their upcoming RISC-V releases will run on QEMU only. I don't think that
was a very clever move. In the end, software should support use case and not just be
pet projects of developers.

Adrian

PS: Please avoid posting to debian-ports@ as this address reaches ALL ports mailing lists.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#89787

On Mon, Oct 27, 2025 at 11:20:29AM +0100, Marcin Juszkiewicz wrote:
> W dniu 27.10.2025 o 01:15, Jan-Daniel Kaplanski pisze:
> 
> > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8
> > from 2005[2]. I highly doubt that archaic architecture has a lot of
> > users besides SBCs up to the generation of RPi 2 and legacy embedded
> > systems that are likely EOL too. Especially since aarch64 came in
> > 2012 with armv8-a on the Cortex-A53/A57[3][4].
> 
> Many people would love to see arm32 go away. Market is still against us and
> arm32 is still sold and used.
> 
> There could be one change done to armhf: enabling NEON by default as Tegra2
> is long time gone.
>...

Atmel SAMA5D3 is still in production, and popular for low-end embedded devices.

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#89790

On 2025-10-27 13:31, Adrian Bunk wrote:
> Atmel SAMA5D3 is still in production, and popular for low-end embedded devices.

Data point: At work we use exactly that with Debian. Home baken kernel, though.

[toc] | [prev] | [next] | [standalone]

#89794

On Mon, Oct 27, 2025, at 12:31, Adrian Bunk wrote:
> On Mon, Oct 27, 2025 at 11:20:29AM +0100, Marcin Juszkiewicz wrote:
>> W dniu 27.10.2025 o 01:15, Jan-Daniel Kaplanski pisze:
>> 
>> > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8
>> > from 2005[2]. I highly doubt that archaic architecture has a lot of
>> > users besides SBCs up to the generation of RPi 2 and legacy embedded
>> > systems that are likely EOL too. Especially since aarch64 came in
>> > 2012 with armv8-a on the Cortex-A53/A57[3][4].
>> 
>> Many people would love to see arm32 go away. Market is still against us and
>> arm32 is still sold and used.

I think it's important to understand the nuance here, as it's easy
to get mixed up. These things can be true simultaneously:

- There are countless embedded systems running Debian/armhf that still expect
  to need support for many years to come.
- Chips like i.MX6 (released in 2011) is still being deployed in new boards
  this year and will ship until 2036, similar to expected supported lives
  for STM32 and Microchip SAMA7 products and others.
- Most companies that have shipped i.MX6 based boards in the past are now
  shipping 64-bit i.MX8 for newer products.
- There are several still new Cortex-A7 based low-end chips every year
- Almost every SoC company that shipped a Cortex-A7 based SoC in the
  past has replaced that with a Cortex-A35 in the last 5 years.
- Until about 2021, the majority of new embedded machines were ARMv7,
  now it's about 10-20%, but that's still more than 64-bit RISC-V.
- As far as I can tell, the new Cortex-A7 based chips tend to not
  run Debian, since they are made for the ultra-low-cost market,
  where you'd rather spend the development fit into smaller RAM
  with a custom build

>> There could be one change done to armhf: enabling NEON by default as Tegra2
>> is long time gone.
>>...
>
> Atmel SAMA5D3 is still in production, and popular for low-end embedded devices.

SAMA5D3 is an interesting corner case, possibly the only ARMv7+VFPv3d16
chip you can still buy after the end of Tegra2 and ArmadaXP (which still
have users).

I would still agree with Marcin here: SAMA5D3 was Atmel's first attempt
at an ARMv7 chip back in 2013, and everything after it had NEON including
the 2014 SAMA4D4 and of course all the SAMA7. It only has DDR2/LPDDR2
support, which means it's no longer cost-effective compared to newer
chips with DDR3. I would expect even SAM9X7 to be much more popular
than SAM5A3 in ongoing production: SAM9X7 is only an ARM926 and won't
run anything newer than Trixie/Armel, but it does have modern I/O
and DDR3 memory. If dropping SAM9x7 (along with all other v5/v6)
support made sense for sid, then so should dropping support for the
SAMA5D3/vfpv3d16.

      Arnd

[toc] | [prev] | [next] | [standalone]

#89819

On Mon, Oct 27, 2025 at 10:22:35PM +0100, Arnd Bergmann wrote:
> On Mon, Oct 27, 2025, at 12:31, Adrian Bunk wrote:
>...
> >> There could be one change done to armhf: enabling NEON by default as Tegra2
> >> is long time gone.
> >
> > Atmel SAMA5D3 is still in production, and popular for low-end embedded devices.
> 
> SAMA5D3 is an interesting corner case, possibly the only ARMv7+VFPv3d16
> chip you can still buy after the end of Tegra2 and ArmadaXP (which still
> have users).

SAMA5D3 is ARMv7+VFPv4d16.

While the FPU itself is optional, when it is present it's v4 since A5 is 
a relatively recent (compared to A8/A9) design.

> I would still agree with Marcin here: SAMA5D3 was Atmel's first attempt
> at an ARMv7 chip back in 2013, and everything after it had NEON including
> the 2014 SAMA4D4 and of course all the SAMA7. It only has DDR2/LPDDR2
> support, which means it's no longer cost-effective compared to newer
> chips with DDR3. I would expect even SAM9X7 to be much more popular
> than SAM5A3 in ongoing production: SAM9X7 is only an ARM926 and won't
> run anything newer than Trixie/Armel, but it does have modern I/O
> and DDR3 memory. If dropping SAM9x7 (along with all other v5/v6)
> support made sense for sid, then so should dropping support for the
> SAMA5D3/vfpv3d16.

You are misunderstanding what the problems with armel are.

On the technical side the problem with armel is that the ecosystem is 
crumbling away. Not necessarily at the toolchain side, but e.g. Firefox 
is no longer supporting armel and GNOME uses a copy of Firefox as 
Javascript library and this has several transitive reverse dependencies.

But even more important is the human side.

I suspect the root problem is that while many people who went to 
university in the 90s and 00s picked porting to exotic platforms
as a hobby, students today pick other hobbies.

This was the porter situation for jessie just 10 years ago[1]:
https://release.debian.org/jessie/arch_qualify.html

For the 3 arm architecture I am counting 13 distinct people who 
volunteered as porters.

And 8 porters for Hurd/i386.

There was no porter rollcall for trixie, the situation for bookworm
3 years ago was:
https://release.debian.org/bookworm/arch_qualify.html

3 distinct people who were porters for the 3 arm architectures.

By now the number of people who still have the interest and time to 
commit to constantly do non-trivial porting work for arm on Debian
has gotten even closer to 0.

armel might be salvageable if suddenly a couple of DDs would declare 
their desire to keep it alive and start working on it, but that won't
happen.

>       Arnd

cu
Adrian

[1] mouseover shows the porter names

[toc] | [prev] | [next] | [standalone]

#89827

On 29/10/2025 13:47, Arnd Bergmann wrote:

 > 5. armv6k+vfpv3d16: Most ARMv6/v7 machines, including Raspberry
 >     Pi zero/1 but not OMAP2 (Nokia N800/N810). Loses THUMB2 support
 >     and v7/v8 CPU barriers among other minor differences.

As maintainer of raspbian, I can say the memory barrier issue is
one of the bigger thorns in our side and is the reason we continue
to configure gcc for armv6 rather than armv6k.

For the uninitiated, arm added memory barrier instructions in armv6k,
as instructions on the system coprocessor (aka CP15). When targetting
armv6k, compilers use these instructions to implement
acquire/release/seqcst atomics.

With armv7-a, arm deprecated the CP15 barriers and introduced the
dmb instruction.

The problem is that arm64 kernels by default trap the armv6k memory
barriers into the kernel and emulate them. Asside from being slow
this can also cause hangs if the optimiser moves a barrier inside
a load-exclusive/store-exclusive loop.

I believe there are also some newer CPU cores that simply don't
support the CP15 barriers at all.

[toc] | [prev] | [next] | [standalone]

#89828

On 30/10/2025 08:28, Arnd Bergmann wrote:
> On Thu, Oct 30, 2025, at 06:39, Peter Green wrote:
>> On 29/10/2025 13:47, Arnd Bergmann wrote:
>>
>>   > 5. armv6k+vfpv3d16: Most ARMv6/v7 machines, including Raspberry
>>   >     Pi zero/1 but not OMAP2 (Nokia N800/N810). Loses THUMB2 support
>>   >     and v7/v8 CPU barriers among other minor differences.
>>
>> As maintainer of raspbian, I can say the memory barrier issue is
>> one of the bigger thorns in our side and is the reason we continue
>> to configure gcc for armv6 rather than armv6k.
>>
>> For the uninitiated, arm added memory barrier instructions in armv6k,
>> as instructions on the system coprocessor (aka CP15). When targetting
>> armv6k, compilers use these instructions to implement
>> acquire/release/seqcst atomics.
>>
>> With armv7-a, arm deprecated the CP15 barriers and introduced the
>> dmb instruction.
>>
>> The problem is that arm64 kernels by default trap the armv6k memory
>> barriers into the kernel and emulate them. Asside from being slow
>> this can also cause hangs if the optimiser moves a barrier inside
>> a load-exclusive/store-exclusive loop.
> Right, this is very unfortunate, and I suspect that this is something
> we should change in both the arm64 kernel and in the compiler. If
> you can point me to specific userspace code that has this problem,
> I can probably come up with a kernel patch to work around it,
> at least if that userspace code isn't obviously wrong.
https://github.com/rust-lang/rust/issues/53670

[toc] | [prev] | [next] | [standalone]

#89829

On Thu, Oct 30, 2025, at 09:47, Peter Green wrote:
> On 30/10/2025 08:28, Arnd Bergmann wrote:
>> On Thu, Oct 30, 2025, at 06:39, Peter Green wrote:
>>> The problem is that arm64 kernels by default trap the armv6k memory
>>> barriers into the kernel and emulate them. Asside from being slow
>>> this can also cause hangs if the optimiser moves a barrier inside
>>> a load-exclusive/store-exclusive loop.
>> Right, this is very unfortunate, and I suspect that this is something
>> we should change in both the arm64 kernel and in the compiler. If
>> you can point me to specific userspace code that has this problem,
>> I can probably come up with a kernel patch to work around it,
>> at least if that userspace code isn't obviously wrong.
> https://github.com/rust-lang/rust/issues/53670

Thanks for the pointer! This strongly suggests that the bug is
in llvm itself, not in userspace applications or the kernel.
I think the armv7-a version of the reproducer shows the same bug,
though that happens to work. This is probably one of the cases
where we want a compiler fix first, but can then add a workaround
in the host kernel (enabling the instruction itself instead of
the emulation where possible, same as the Raspberry Pi downstream
kernel does).

     Arnd

[toc] | [prev] | [next] | [standalone]

#89832

On Wed, Oct 29, 2025 at 02:47:13PM +0100, Arnd Bergmann wrote:
> On Wed, Oct 29, 2025, at 08:39, Adrian Bunk wrote:
>...
> >> I would still agree with Marcin here: SAMA5D3 was Atmel's first attempt
> >> at an ARMv7 chip back in 2013, and everything after it had NEON including
> >> the 2014 SAMA4D4 and of course all the SAMA7. It only has DDR2/LPDDR2
> >> support, which means it's no longer cost-effective compared to newer
> >> chips with DDR3. I would expect even SAM9X7 to be much more popular
> >> than SAM5A3 in ongoing production: SAM9X7 is only an ARM926 and won't
> >> run anything newer than Trixie/Armel, but it does have modern I/O
> >> and DDR3 memory. If dropping SAM9x7 (along with all other v5/v6)
> >> support made sense for sid, then so should dropping support for the
> >> SAMA5D3/vfpv3d16.
> >
> > You are misunderstanding what the problems with armel are.
> >
> > On the technical side the problem with armel is that the ecosystem is 
> > crumbling away. Not necessarily at the toolchain side, but e.g. Firefox 
> > is no longer supporting armel and GNOME uses a copy of Firefox as 
> > Javascript library and this has several transitive reverse dependencies.
> 
> I don't see a fundamental difference here, but rather a gradual
> step where cutting off at a particular architecture level loses
> a set of users that are on older hardware as well as a set of
> developers that only care about newer hardware.
> 
> > By now the number of people who still have the interest and time to
> > commit to constantly do non-trivial porting work for arm on Debian
> > has gotten even closer to 0.

You are talking about hardware support.
I am talking about lack of porters.

If there were hard porter criteria based on what would have been 
considered a reasonable minimum porter activity a decade ago,
then our only potential 32-bit release architecture would be hppa.

Even arm64 might not qualify.


> > armel might be salvageable if suddenly a couple of DDs would declare 
> > their desire to keep it alive and start working on it, but that won't
> > happen.
> 
> Absolutely, and it makes total sense that there is only one 32-bit
> Arm target remaining in Debian, which in turn has to set a baseline
> that maximises the number of users but is new enough to reduce the
> work on the DD side.
> 
> Hypothetically, I could se (at least) these eight options for a
> baseline if there can only be one:
> 
> 1. armv8-aarch32+neon: loses all 32-bit hardware, only for
>    compat mode on arm64 kernels, e.g. memory-optimized containers
>    in cloud systems. Widely available for developers.
> 2. armv7ve+vfpv4d16+neon: runs on most currently shipping systems
>    (cortex-a7) but loses most existing systems (cortex-a9 and
>    older). Architecturally very similar to 1.
> 3. armv7-a+vfpv3d32+neon: Almost all ARMv7 systems, except Tegra2,
>    ArmadaXP/370, Dove and SAMA5AD3 (probably others without
>    upstream kernel support).
>    Same baseline as Android and Arch Linux, misses FP16, FMA and
>    IDIV instructions.
> 4. armv7-a+vfpv3d16: Current baseline, same as Ubuntu and
>    OpenSUSE, loses NEON support.
> 5. armv6k+vfpv3d16: Most ARMv6/v7 machines, including Raspberry
>    Pi zero/1 but not OMAP2 (Nokia N800/N810). Loses THUMB2 support
>    and v7/v8 CPU barriers among other minor differences.
> 6. armv6+vfpv3d16: All ARMv6 machines including OMAP2 but loses
>    modern atomics used in locking primitives. Currently used on
>    Raspbian and a few other v6 distros that target Raspberry Pi.
> 7. armv5+vfpv2d16: lowest possible baseline for armhf compatible
>    ABI, used in LPC32xx, but requires libatomic for even more
>    cases.
> 8. armv5 softfloat: current baseline for armel,  largest amount
>    of supported hardware in total, but loses both VFP and NEON
>    optimizations in addition to the other problems above.
> 
> The only realistic choices I see here are 3, 4 and 5, with good
> arguments in favor of each one.  Between these, I see both NEON
> and Thumb2 as important features that some developers are taking
> for granted the same way as hardfloat, though admittedly to a
> lesser degree. Changing from 4 to 3 would lose a very small number
> of users but gain an important feature, while going from 4 to 5
> would lose an important feature but gain a much larger number of
> (Raspberry Pi) users that previously had to use armel. Staying with
> 4 is of course the easy choice because it means not having to
> change anything.

Regarding option 5:

The baseline is encoded in a gazillion places, these need fixes
(though raspbian already has fixes for most).

And then you need a rebuild of the full archive.

It might be doable to basically merge raspbian into Debian
(but it would be weird to do that now and not a decade ago).

A relevant question would be how many and which packages are not 
buildable on raspbian due to the lower baseline.

In any case this option would be a lot of work.


Regarding option 3:

The amount of work would be trivial, since asking the GCC maintainer
to change the baseline would be the only mandatory part of the change
(we did this on armel when raising the baseline from armv4te to armv5te
in buster).

Due to the common baseline without NEON most relevant software that 
benefits from NEON got runtime detection 1-2 decades ago.

Due to armhf being a legacy platform today, it is unlikely that 
important software will suddenly make NEON a hard requirement
now - it is more common that a package drops  armhf support,
or more commonly support for 32-bit.

If the only tradeoff is between hardware support and marginal 
performance improvements, that's not a good case for dropping
hardware support - and anyone who cares about performance
should anyway not be using armhf in 2027.


>       Arnd

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#89793

On 10/27/25 05:20, Marcin Juszkiewicz wrote:
> W dniu 27.10.2025 o 01:15, Jan-Daniel Kaplanski pisze:
> 
>  > Besides, the armhf baseline of armv7-a+fp aligns with the Cortex-A8
>  > from 2005[2]. I highly doubt that archaic architecture has a lot of
>  > users besides SBCs up to the generation of RPi 2 and legacy embedded
>  > systems that are likely EOL too. Especially since aarch64 came in
>  > 2012 with armv8-a on the Cortex-A53/A57[3][4].
> 
> Many people would love to see arm32 go away. Market is still against us 
> and arm32 is still sold and used.

It's funny how the push to make architectures go away corresponds with 
the patent expiration on those architectures, I.E. the point at which 
clones (compatible reimplementations) can start being sold very cheaply.

Proprietary commercial vendors want to kill their competition. "Many 
people" work for hardware vendors who not only stop selling things when 
their patents expire, but actively want support for stuff they were just 
recently selling to go away.

Rob

[toc] | [prev] | [next] | [standalone]

#89786

On Sun, Oct 26, 2025 at 01:21:29PM +0100, Bastian Blank wrote:
> Hi

Hi Bastian,

> We never did a real discussion about architecture baselines before, but I think
> we should do that.  We also don't have any guidelines what we as Debian want to
> actually support.  But given that we are a general purpose distribution, we
> have to find a balance.

you did not provide data to show what your "balance" is about,
and discussions not based on data are rarely productive.

Your proposal would make many users unhappy, it would be you who has to 
show the benefits.

Whether your proposal to drop support for v1 amd64 hardware is even 
worth discussing depends a lot on whether the typical performance 
improvement is 2% or 20%.

It would also be useful to have data for security hardening in this 
discussion.

We are shipping an additional version of the Python interpreter built 
without PIE because this one hardening feature alone had a large enough
negtive impact on performance that it was not suitable for some users.

Typical for a discussion not based on data would be if it later turns 
out that there was a huge discussion with GR and everything about
something that only makes 2% difference, but building HPC software
with hardening flags costs 20%.

> As a general guidance I would like to aim for a ten to 15 years support range
> at release time.  The cutoff in respect to the expected 2027 release date of
> Forky would therefor be 2012 to 2017.  More time is given for widely used
> architectures, less for more specialized ones.
>...
> ## amd64 (and i386)
> 
> * x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9x86].
> * x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
>   10[^redhat10].

What RHEL uses is not particularly relevant, since enterprise 
distributions do not target the cheap low-end systems that are
manufactured and used for a long time.

> I propose to use the x86-64-v2 baseline in Forky.
> It gives us more then the 15 years
>...

You are talking about the mostly irrelevant "supported by one CPU" date.

It is also telling that you aren't mentioning v4, which was supported by 
Intel desktop CPUs in the past - but current Intel desktop and laptop CPUs
are not supporting it.

Based on your proposal, you want us to drop support for Intel desktops 
and laptops sold today in 4-9 years.

Actually relevant would be the date when the last CPU was sold that did 
not support the new baseline.

15 years after the last CPU was sold would be a point where usage 
becomes quite low.

Even the introduction of the most recent new v1 CPU was not more than
10 years ago, we are still at least a decade away from the point where
v1 usage could be called retro computing.

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#89792

[dropping debian-ports since I saw a request for that in the thread]

On Sun, Oct 26, 2025 at 01:21:29PM +0100, Bastian Blank wrote:
>## amd64 (and i386)
>
>* x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9x86].
>* x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
>  10[^redhat10].
>
>I propose to use the x86-64-v2 baseline in Forky.  It gives us more then the 15
>years and everyone else already switched to it or even a newer variant.
>Factoring in a possible LTS for Trixie, this means that x86-64-v1 will stop
>being supported by Debian in 2030.

CERN spoke at DebConf [1] and indicated that ~47% of their accelerator 
control fleet runs x86-64-v1, which due to a cascading series of 
replacement costs meant that they estimated a budget of about €7M to 
migrate from CentOS 7 to CentOS Streams 9.  As a result they chose to 
switch to Debian instead, and they said that their plan A was to use 
trixie and upgrade to forky in 2030.  If I understood them correctly, 
they did say (in the Q&A) that there was a plan to upgrade to at least 
x86-64-v2 in the 2034 long shutdown, but that it was still a complex 
project with the possibility of being derailed by operational issues.

Has anyone consulted with them about how this would affect their plans?  
They're a pretty significant organization and I know a lot of Debian 
developers would like to keep them being able to use Debian.

[1] https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-605-approaching-the-speed-of-light-with-debian-debians-role-in-the-worlds-largest-particle-accelerator.av1.webm

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#89831

Hi all,

On Mon, 27 Oct 2025, at 19:22, Colin Watson wrote:
> CERN spoke at DebConf [1] and indicated that ~47% of their accelerator 
> control fleet runs x86-64-v1, which due to a cascading series of 
> replacement costs meant that they estimated a budget of about €7M to 
> migrate from CentOS 7 to CentOS Streams 9.  As a result they chose to 
> switch to Debian instead, and they said that their plan A was to use 
> trixie and upgrade to forky in 2030.  If I understood them correctly, 
> they did say (in the Q&A) that there was a plan to upgrade to at least 
> x86-64-v2 in the 2034 long shutdown, but that it was still a complex 
> project with the possibility of being derailed by operational issues.
>
> Has anyone consulted with them about how this would affect their plans?  
> They're a pretty significant organization and I know a lot of Debian 
> developers would like to keep them being able to use Debian.

I am one of the presenters of said talk :) Thanks for the mention.
 
<CERN engineer hat on>
To give our perspective, as you mentioned correctly, we have numerous v1 machines that we'd love to upgrade by 2030, but it is very challenging. If this change is adopted for Forky it'll put a wrench in our "Plan A", which was to follow the Debian LTS release cycle and instead will have to freeze our infrastructure to Trixie until LS4 (2034). It'd also put a question mark into our choice of Debian as the distribution for our most heterogeneous class of systems. The change in RedHat was a bit surprising but as a "server-focused" OS we could justify why it was made. We then picked Debian in part because of its focus into compatibility with a wide range of systems, from x86 to embedded devices, only to be having the same discussion now.
</CERN engineer hat off>

<DM Hat on>
My opinion as a DM and Debian user is that this is a change that will have to be carefully evaluated, do we have any tests or benchmarks on what are the benefits, performance or otherwise? There have been many responses to this thread already outlining all of the arguments on both sides, so I will not repeat them here, but my opinion is that until now with every machine I picked up I would never question "can it run Linux/Debian?", it was always a given. Reading the arguments on both sides, I tend to agree on the fact that we should aim to support as many systems as possible as long as it is feasible. Then again, if something drastic happens like kernel upstream decides to drop support for these architecture versions, then it can be re-discussed. Required effort vs benefit and all that.

However, even the Debian website seems to have quite a few mentions to that effect as well[1].

" Windows 10 support ends in October 2025. Your computer may not run Windows 11, but it will run Debian for many more years without buying new hardware. Debian supports the End of 10 campaign."

"Debian has extensive Hardware Support.
    Most hardware is supported by the Linux kernel which means that Debian will support it as well"
</DM Hat off>

I'll keep a keen eye on how this thread evolves. I'm open to hear any arguments for/against the above.

Cheers,
Nikos

[1] https://www.debian.org/intro/why_debian

--
BE-CSS-ISA
Accelerator Control Systems General System Administration

[toc] | [prev] | [next] | [standalone]

#89795

On 10/26/25 8:21 AM, Bastian Blank wrote:
> Hi

Hi Bastian,

> 
> We never did a real discussion about architecture baselines before, but I think
> we should do that.  We also don't have any guidelines what we as Debian want to
> actually support.  But given that we are a general purpose distribution, we
> have to find a balance.
> 
> As a general guidance I would like to aim for a ten to 15 years support range
> at release time. 


It would be more reasonable to count 7 years since mass sales or wide 
availability ends as hardware typically lasts 5 to 7 years in production 
environment.

Milan

[toc] | [prev] | [next] | [standalone]

#89798

On Mon, Oct 27, 2025 at 05:38:57PM -0400, Milan Kupcevic wrote:
> It would be more reasonable to count 7 years since mass sales or wide
> availability ends as hardware typically lasts 5 to 7 years in production
> environment.

z14 was end of life/sale in 2021 and will be end of service in 2026.
power8 must have been end of life/sale in 2019 and is end of service in 2024.
he latest niche x86-64-v1 cpu was introduced in 2015, and i doubt it
was produced for more then five years.

So not much change, just different numbers.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!

[toc] | [prev] | [next] | [standalone]

#89808

On Mon, Oct 27, 2025 at 11:12:03PM +0100, Bastian Blank wrote:
>On Mon, Oct 27, 2025 at 05:38:57PM -0400, Milan Kupcevic wrote:
>> It would be more reasonable to count 7 years since mass sales or wide
>> availability ends as hardware typically lasts 5 to 7 years in production
>> environment.
>
>z14 was end of life/sale in 2021 and will be end of service in 2026.

I am not sure why we should orient ourselves after end of life and end 
of service dates set by the vendors, surely with revenue in the back of 
their heads.

I know that we MUST orient ourselves at the support for kernel and 
toolchains.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web