Re: Future of armv7

On Sat, Nov 15, 2025 at 9:24 AM Adrian Chadd <adrian@freebsd.org> wrote:

>
>
> On Fri, 14 Nov 2025 at 09:09, John Baldwin <jhb@freebsd.org> wrote:
>
>> Two and a half years ago when we first began talking about deprecating
>> 32-bit architectures in 15.0, we decided to keep armv7 for at least
>> the stable/15 branch but did not commit to anything beyond that.  Now
>> that 15.0 is close to shipping and we are turning our development
>> focus to 16.0, we should figure out what we want to say about armv7
>> for 16.x in the 15.0 release notes so that users have suitable notice.
>>
>> In particular, do we want to deprecate armv7 in 16.0 (similar to the
>> state of 32-bit powerpc in 15.0), or do we want to keep it?
>>
>> My initial suggestion is that we announce that we plan to deprecate it
>> in 16.0.  In that case, I would also suggest that we follow a similar
>> process of keeping armv7 for most of the lifetime of 16.0 so that we
>> can reneg if need be during the 16.0 cycle.
>>
>> What do other folks think?
>>
>
> There still seems like there's plenty of users of armv7 hardware out there.
>

There is. However, there's also plenty of armv5 hardware out there too. This
is a necessary argument, but it's not sufficient.


> Outside of the raspberry pi ecosystem where people are still using the
> armv7
> cores, and some of the armv7 qualcomm parts i do armv7 testing on,
> what's being made?
>
> It'd be a shame to EOL it IMHO.
>

True. However, there's some more factors.

The following all must be true for us to keep an architecture.
(1) Do we have users? Without users, there's no benefit to keeping it. We
need a large enough base to provide enough benefit for the cost.
(2) We need to have a core group of developers that are maintaining, at
least, and ideally expanding the technology.
(3) The burden to all the FreeBSD developers for this architecture has to
be out weighted by the benefit.

So (1) is true since we have users, but their numbers are dwindling. All
the data we have shows this. Some people are still using it, but it's a lot
fewer than 2 years ago. Projected into the future: will we have enough
users to make it worthwhile in 2 years so that we commit to another 4-5
years of support then? That's unclear. In fact, I suspect during the
lifetime of the 15 branch that the numbers will fall off
significantly (though I may be wrong).
(2) is borderline right now. We have some people fixing some bugs on armv7,
but it's a very laggy process (look at the jemalloc assert (on signal?) for
an easy to understand example). These numbers have been falling for years,
and I don't see that we have new people taking the place of people that
have moved on. And history has shown that we rarely get new developers when
we commit for another cycle. It certainly didn't happen between 14 and 15
for armv7.
(3) Each architecture has a burden. armv7 is not a direct mapped
architecture, so we have to do many optimizations twice: Once for direct
map and once with page flipping for armv7. uint32_t and uint64_t are
declared differently, so we have the perennial problem of accidental printf
breakage (easy to fix, sure, and we now have more tools to provent that,
but they are slow to roll out). And there's algorithms that are fast for
the latest hardware that are VA space greed, that won't work on armv7. And
that's not even getting into the logistical issues with armv7: native
builds are difficult because compilers are used to huge address spaces that
armv7 doesn't support, so in addition to the jemalloc assert, we hit OOM
situations more often. Plus things like rust, go and other languages are
hit or miss on armv7 (and that's been true for years), limiting it's
usefulness even further.

So there's a significant burden for a declining user base with a shrinking
developer pool to fix the problems *TODAY*. Where are we going to be when
we look out 2 years? Likely no better, but more burden, less resources and
fewer users. While the future is hard, there's an excellent likelihood of
this outcome. We should prepare people today for that likely outcome rather
than lead them on only to deliver increasingly poor quality to people that
try to use it. If things change, and there's more update, more cool devices
that draw in more users, etc, we can always change our plans. But absent
that, keeping it for nostalgia is a bad bet. sparc64 was dead for years
before we removed it, so we've learned to be more aggressive about removal.
And the warning signs are there with armv7...  And we gave sparc64 far too
many chances when people came out of the woodwork yelling "no!" and then
faded back into the woodwork when work was needed...

So, this isn't a final decision. We'd keep armv7 on at least until close to
the 16 branch (unless things totally tank before then, which is unlikely),
which will allow easier MFC and also gives the community a chance to devote
the resources to the port it needs to save it. But there needs to be some
demonstrable benefit to exert effort and ask everybody to exert effort to
maintain it.

Warner