Future of 32-bit platforms (including i386)

[John Baldwin]

For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announcement
of this for 13.0, the project committed to an update on i386's future
around the time of 14.0. The announcement at the time suggested that
i386 would be supported less in 14.x than in 13.x.

My proposal is that for 14.x we treat i386 like any other Tier 2
platform. That is, release images and packages would only be provided
on a best-effort basis, and we would not guarantee providing them. I
think we should also stop shipping binary updates for the base system
(freebsd-update) for 14.x for i386.

A larger question is what to do about 32-bit platforms moving forward.
My proposal for powerpc, i386, and armv[67] is that we say publicly
that we anticipate not supporting them in 15. That is, that we may
remove them outright from the tree, or we may leave them in the tree,
but we do not plan on building packages or release images. Another
option to consider for 32-bit platforms perhaps in 15 is to remove
kernel support and only retain the ability to build userland. The
goal of saying this now-ish (or about the time 14.0 is going to ship)
would be to give time for users and developers to respond in the
window between 14.0 and 15.0 so we can evaluate those responses as an
input into the final decision for 15.

--
John Baldwin

[Poul-Henning Kamp]

--------

John Baldwin writes:

> A larger question is what to do about 32-bit platforms moving forward.
> My proposal for powerpc, i386, and armv[67] is that we say publicly
> that we anticipate not supporting them in 15.

If we do, the first two questions we will get back are:

1. When does 15 happen ?

2. How long time will some branch of 14 be supported ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Warner Losh]

On Thu, Apr 27, 2023 at 11:20 AM John Baldwin <j...@freebsd.org> wrote:

For 13.0, i386 was demoted from Tier 1 to Tier 2.  In the announcement
of this for 13.0, the project committed to an update on i386's future
around the time of 14.0.  The announcement at the time suggested that
i386 would be supported less in 14.x than in 13.x.

I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe?

 

My proposal is that for 14.x we treat i386 like any other Tier 2
platform.  That is, release images and packages would only be provided
on a best-effort basis, and we would not guarantee providing them.  I
think we should also stop shipping binary updates for the base system
(freebsd-update) for 14.x for i386.

So no freebsd-update service for i386 for 14.x, but have it for arm64 and amd64?

That seems reasonable (assuming that arm64 works).

 

A larger question is what to do about 32-bit platforms moving forward.
My proposal for powerpc, i386, and armv[67] is that we say publicly
that we anticipate not supporting them in 15.  That is, that we may
remove them outright from the tree, or we may leave them in the tree,
but we do not plan on building packages or release images.  Another
option to consider for 32-bit platforms perhaps in 15 is to remove
kernel support and only retain the ability to build userland.  The
goal of saying this now-ish (or about the time 14.0 is going to ship)
would be to give time for users and developers to respond in the
window between 14.0 and 15.0 so we can evaluate those responses as an
input into the final decision for 15.

I like this idea. It states intent strongly enough that people aren't surprised,

but weakly enough that people with strong interests can show up. One lesson

we've learned repeatedly in the past, though, is that we get a lot people

showing up saying they'll do something, but then doing nothing. The threshold

of doing something will be actually doing it and being an active member of

the community or providing other material support rather than "Geeze, I'd

hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd set

that expectation, but maybe something like "we'll evaluate the responses and

the robustness, size and vitality of those communities as input into our decision"

which would set the bar higher, and have something vaguely measureable to

point at.

Side note: We should stop providing packages and re-built images for armv6

in 14, even if we don't completely decommission support for it right away. That

might prove to be a good model here as well and give us some good experience

for how to do that with the other 32-bit platforms for 15.

I generally favor this idea... It's also a natural evolution of what we've been saying

about platforms, eg you need to provide 64-bit atomics and other operations,

even if they are relatively inefficient because the base system is starting to use them.

32-bit going away is the long term trend, and the long term goal of the project.

What remains in doubt is the timeline to accomplish this. Many 32-bit platforms

still perform decently well, so we should expect to see some usage. But we need

to weigh the size of that usage against the cost of providing it. We've seen an increasing

cost to developers to provide this over the last few years. But as the usage drops

the cost increases because unanticipated breakages become harder to fix as they

are discovered further and further from the breaking point.

Warner

[Warner Losh]

On Thu, Apr 27, 2023 at 11:32 AM Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:

--------
John Baldwin writes:

> A larger question is what to do about 32-bit platforms moving forward.
> My proposal for powerpc, i386, and armv[67] is that we say publicly
> that we anticipate not supporting them in 15.

If we do, the first two questions we will get back are:

1. When does 15 happen ?

Late 2025, give or take 6 months would be our recent cadence. while we might want to change

this cadance, any decision here should likely assume that cadence and we can make adjustments

to the plan based on a hypothetically changed cadence would bring. So we'd plan on removing

the 32-bit platforms sometime in 2024 or early 2025 at the latest, but as soon as the end of this

year. So you'd no longer be able to run 'main' on these platforms after a year or two.

 

2. How long time will some branch of 14 be supported ?

At least until 2027 if history is a guide (de-facto is about 2 years after the next major branch) with

fading levels of support. I think the 'support model' would place it around June 2028 somewhere

assuming we release 14 in June. There's clearly some fuzziness here, but for planning purposes

one should expect updates to trail off in late 2026 or early 2027 and critical updates stopping

sometime before 2028. At least that's what I'm observing with EOL of 12 that's pending... as

well as what's happened more organically for 10 and 11.

Of course, the above is my opinion, and it's phrased such as to give some less vague timelines to

John's proposal.

Is this helpful?

Warner

[Robert Clausecker]

I would very much appreciate if lib32 support stays in (or is completed
in the case of aarch64). Without it, FreeBSD becomes a lot less useful
as a well rounded development system as you can no longer test code for
32 bit platforms. I also have a need for armv7 user space code in
particular as I participate in and maintain the FreeBSD port of a Forth
system written in armv7 assembly. Being able to run the same code you
run on a microcontroller on a hosted platform makes it a lot easier to
test and develop.

As for running 32 bit kernels, I do not really have an opinion.

Yours,
Robert Clausecker

--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments

[Mark Millard]

Robert Clausecker <fuz_at_fuz.su> wrote on
Date: Thu, 27 Apr 2023 18:18:55 UTC :

> I would very much appreciate if lib32 support stays in (or is completed
> in the case of aarch64). Without it, FreeBSD becomes a lot less useful
> as a well rounded development system as you can no longer test code for
> 32 bit platforms. I also have a need for armv7 user space code in
> particular as I participate in and maintain the FreeBSD port of a Forth
> system written in armv7 assembly. Being able to run the same code you
> run on a microcontroller on a hosted platform makes it a lot easier to
> test and develop.

What I do for armv7 on aarch64 is to install an armv7
world into a directory tree and chroot into that world.
As I understand jails also work. One can install armv7
ports and such in the alternate world.

But I do not use X11 or other such so my range of
experience is limited and there could be issues that
I just do not know about.

> As for running 32 bit kernels, I do not really have an opinion.

For reference, for some examples details , including
some things not mentioned:

# ls -Tld /usr/obj/DESTDIRs/main-CA7-*/
drwxr-xr-x 19 root wheel 22 Jul 14 13:17:19 2022 /usr/obj/DESTDIRs/main-CA7-chroot/
drwxr-xr-x 18 root wheel 21 Apr 25 01:50:22 2023 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a/
drwxr-xr-x 18 root wheel 21 Apr 25 01:51:29 2023 /usr/obj/DESTDIRs/main-CA7-poud/

# more ~/do-chroot-main-CA7.sh
#! /bin/sh
mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \
&& mount -tdevfs devfs /usr/obj/DESTDIRs/main-CA7-chroot/dev/ \
&& mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-CA7-default/ \
&& mount_nullfs /usr/local/poudriere/data/packages/main-CA7-default \
/usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-CA7-default/ \
&& mkdir -p /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ \
&& mount_nullfs /usr/ports /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/ \
&& env IN_CHROOT="main-CA7-chroot" chroot /usr/obj/DESTDIRs/main-CA7-chroot/
umount /usr/obj/DESTDIRs/main-CA7-chroot/usr/ports/
umount /usr/obj/DESTDIRs/main-CA7-chroot/usr/local/poudriere/data/packages/main-CA7-default/
umount /usr/obj/DESTDIRs/main-CA7-chroot/dev/

(IN_CHROOT is just a personal thing: not required.)

# poudriere jail -l
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
main-CA53 14.0-CURRENT arm64.aarch64 null 2021-06-27 17:57:33 /usr/obj/DESTDIRs/main-CA53-poud
main-CA7 14.0-CURRENT arm.armv7 null 2021-06-27 17:58:33 /usr/obj/DESTDIRs/main-CA7-poud
main-CA7-bulk_a 14.0-CURRENT arm.armv7 null 2021-12-04 14:54:10 /usr/obj/DESTDIRs/main-CA7-poud-bulk_a
main-CA72 14.0-CURRENT arm64.aarch64 null 2021-06-27 17:48:11 /usr/obj/DESTDIRs/main-CA72-poud
main-CA72-bulk_a 14.0-CURRENT arm64.aarch64 null 2021-12-04 14:54:44 /usr/obj/DESTDIRs/main-CA72-poud-bulk_a
main-CA78C 14.0-CURRENT arm64.aarch64 null 2023-04-26 18:55:46 /usr/obj/DESTDIRs/main-CA78C-poud
main-CA78C-bulk_a 14.0-CURRENT arm64.aarch64 null 2023-04-26 18:56:06 /usr/obj/DESTDIRs/main-CA78C-poud-bulk_a

I do the building of packages from ports without doing
a chroot first. But /usr/obj/DESTDIRs/main-CA7-poud and
/usr/obj/DESTDIRs/main-CA7-poud-bulk_a are again
directorties with armv7 worlds installed, but with:

installworld distrib-dirs distribution DB_FROM_SRC=1

as is appropriate for poudriere using the world.

===
Mark Millard
marklmi at yahoo.com

[Hans Petter Selasky]

On 4/27/23 19:19, John Baldwin wrote:
> For 13.0, i386 was demoted from Tier 1 to Tier 2.  In the announcement
> of this for 13.0, the project committed to an update on i386's future
> around the time of 14.0.  The announcement at the time suggested that
> i386 would be supported less in 14.x than in 13.x.

Hi,

This makes me think about all the issues about the "long" type in the
past, and printf() and more, being caught when compiling TARGET_ARCH=i386 .

Maybe just put the following line of code somewhere central :-)

_Static_assert(sizeof(long) == 8);

Will there ever be some kind of hybrid CPU systems?

4 cores AMD64, 4 cores AARCH64 and some virtual QEMU CPUs all running on
the same system?

I mean, the arm vs intel battle is not going to end soonish. And
emulating CPUs is slow and waste electricity. Why not have one computer
having both kind of CPUs, and one OS, and one harddisk? And figure out a
common ABI allowing seamless task switching between them? I know there
are some hard differences, but can't those be ironed out?

--HPS

[Jessica Clarke]

I don’t know where to start with this other than to give an emphatic no to almost all of what you said, or at least the bits for which meaning can be extracted. Regardless, this is not the place for such pie-in-the-sky discussions; if you want to theorise about weird and wacky computer architectures then please take it elsewhere.

Jess

[Poul-Henning Kamp]

--------

Warner Losh writes:

> > If we do, the first two questions we will get back are:
> >
> > 1. When does 15 happen ?
> >
>

> Late 2025, give or take [...]

My point was not so much which specific answers we agree on, as on
including those answers, up front, in the 32bit deprecation notice
up.

[John Baldwin]

On 4/27/23 10:29 PM, Poul-Henning Kamp wrote:
> --------
> Warner Losh writes:
>
>>> If we do, the first two questions we will get back are:
>>>
>>> 1. When does 15 happen ?
>>>
>>
>> Late 2025, give or take [...]
>
> My point was not so much which specific answers we agree on, as on
> including those answers, up front, in the 32bit deprecation notice
> up.

That's a good point, and assuming we do settle on a consensus here,
we should include some ballparks on those dates in the final
announcement.

--
John Baldwin

[Cy Schubert]

Agreed. This brings us in line with virtually all major Linux
distributions, Oracle Solaris (whatever is left of it), the other major
commercial O/S out there (AIX), and the other major distributions of
BSD (except NetBSD).

I think we need to nudge the ports team in this direction, sooner than
later, though in my experience, a good percentage of packages fail to
build on i386 anymore here anyway, including all browsers in ports/www.

>
> Warner



--
Cheers,
Cy Schubert <Cy.Sc...@cschubert.com>
FreeBSD UNIX: <c...@FreeBSD.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org

e^(i*pi)+1=0

[Hans Petter Selasky]

Hi Jess,

I'd like to know why you think this is a wacky idea, to have a super-set
computer architecture, where each CPU can run the full instruction set
of both ARM64 and AARCH64 at the same time.

You have an open invitation for a video call on FaceBook or whatever you
prefer to talk about this. Send me something off-list.

--HPS

[Mehmet Erol Sanliturk]

It is not necessary to go to a very far distant future .

Assume you have a cluster of boards with different CPUs .

Then schedule execution of your programs with respect to the required CPU on this cluster .

Is this possible with FreeBSD ?

Is it a good or bad idea to have such a facility ?

Mehmet Erol Sanliturk

 

[Simon J. Gerraty]

John Baldwin <j...@freebsd.org> wrote:
> A larger question is what to do about 32-bit platforms moving forward.

FWIW while we do not use i386 kernels anymore
compat32 support is very important.

Some of our daemons are very pointer heavy and up to a certain scale
point, a 32bit app is more memory efficient, of course the 64bit version
can scale much bigger but many customers do not need that.

--sjg

[Rene Ladan]

From my testing chromium still builds on i386, but that platform needs some
more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support
will be purged from the ports tree once 12 goes EOL in 2024, removing i386
and arm 6/7 should be a similar exercise.

René

[Warner Losh]

Of course if we decouple the user land from the kernel, we'll have to carefully coordinate that... and that might also be a consideration for how quickly we move in base: the ability to build 32-bit ports with poudriere.

Warner

[John Baldwin]

Are you able to build your daemons with cc -32 with an amd64 world, or
do you require an i386 world to build against?

--
John Baldwin

[Warner Losh]

If the latter, do you use a chroot to build any ports

Warner

--
John Baldwin

[Simon J. Gerraty]

Warner Losh <i...@bsdimp.com> wrote:
> > Some of our daemons are very pointer heavy and up to a certain scale
> > point, a 32bit app is more memory efficient, of course the 64bit version
> > can scale much bigger but many customers do not need that.
>
> Are you able to build your daemons with cc -32 with an amd64 world, or
> do you require an i386 world to build against?

We don't buildworld, and we do not build 32bit apps as such in our freebsd
tree. We build 32bit libs (and loader) and publish these for use by Junos.

For main we are using -target i386-unknown-freebsd14.0, but clang is not
built as part of freebsd.

I think all we require is compat32 support in the kernel, and the
ability to build libs for i386.

> If the latter, do you use a chroot to build any ports

We do not build any ports.

Thanks
--sjg

[Rebecca Cran]

On 4/27/23 17:50, Jessica Clarke wrote:

> I don’t know where to start with this other than to give an emphatic no to almost all of what you said, or at least the bits for which meaning can be extracted. Regardless, this is not the place for such pie-in-the-sky discussions; if you want to theorise about weird and wacky computer architectures then please take it elsewhere.

It's hard enough to get it right when there's a single instruction set,
as with Arm's big.LITTLE.

For example: https://www.mono-project.com/news/2016/09/12/arm64-icache/

I've also heard of problems of programs crashing due to instructions
supported on one core type not being supported on the other.


--

Rebecca Cran

[Warner Losh]

On Thu, Apr 27, 2023 at 11:20 AM John Baldwin <j...@freebsd.org> wrote:

My proposal is that for 14.x we treat i386 like any other Tier 2
platform.  That is, release images and packages would only be provided
on a best-effort basis, and we would not guarantee providing them.  I
think we should also stop shipping binary updates for the base system
(freebsd-update) for 14.x for i386.

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

contains Intel's plans for the future. They have removed support for booting

16/32-bit and non-UEFI from their firmware as of 2020...

Warner

[John Baldwin]

We discussed this topic during the 15.0 developer summit and the consensus
among the folks present (which is only a subset of our community), is
that there is still interest in supporting armv7 kernels in 15.0, but not
kernels for other platforms. In addition, no one expressed a need for
full 32-bit world support for i386 and powerpc, only for compat32 support
in the kernel, and lib32 (cc -m32) support in userland.

One question for this is if we think we will have sufficient developer
resources to maintain armv7 kernels for the life of stable/15. We can
largely punt on the final decision for that until close to the release of
15.0. I think for what we announce for 14.0 we can still say that we
are generally planning to remove 32-bit kernel and world support in 15.0,
but may consider keeping armv7.

--
John Baldwin

[Tomek CEDRO]

On Sat, May 20, 2023 at 10:14 PM Warner Losh wrote:
> https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
>
> contains Intel's plans for the future. They have removed support for booting
> 16/32-bit and non-UEFI from their firmware as of 2020...

I saw that info too.. but are we going to allow Intel dictate future
of computers and supported platforms to The FreeBSD Project? I am
convinced that everyone will move to RISC-V pretty soon anyway :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

[Tomek CEDRO]

I always think in terms of "Zombie Apocalypse"^TM on what to get
myself into.. if its not going to work in that kind of situation then
its not worth the time :-) :-)

Will "lack of support" mean no binaries provided or removal of the
source code so FreeBSD is non-existent anymore on those platforms?

[Charlie Li]

Both. The actual code would be removed, as there exists a
not-insignificant cost on development of contemporary platform support
(needing to keep i386 around significantly hinders amd64 development,
for instance).

I had a much longer passage on this subject that was slated to be
written and posted here prior to the devsummit, but the tl;dr was
understood at the devsummit. Basically, the proposed general removal of
32-bit support is unfortunate but probably technically necessary.
Investigations of certain use cases, like Wine, will need to happen to
see how much 32-bit userland support need to remain whilst running on
64-bit kernel. There continue to exist production armv7 boards that
enjoy long-term support, so removing kernel support would not only be a
bad idea, but those who need that support the most are the least
equipped to help on our end (unless some individuals can be nudged to
learn).

--
Charlie Li
…nope, still don't have an exit line.

[Konstantin Belousov]

On Tue, May 23, 2023 at 11:59:09PM -0400, Charlie Li wrote:
> Both. The actual code would be removed, as there exists a not-insignificant
> cost on development of contemporary platform support (needing to keep i386
> around significantly hinders amd64 development, for instance).

Can you explain this, please? Exactly how i386 affects a work on amd64?

[Emmanuel Vadot]

I personnaly see armv7 in "degraded maintainance mode" since 13.0,
nothing really intersting was added, no new SoC support even if there
was some interesting one that we could support, no new drivers for
supported platforms. We even lost TI BeagleBone support because no one
really have the time to keep support up to date.
I still have some little cute boards that I want to use from time to
time but the lack of proper porting of new language (like rust and iirc
go have problems too) is making new software unusable on those boards
(you can't even make some "smart speaker" for spotify as all the
spotify clients are in rust).
IMX6 support is stalled since ian@ passed away and mmel@ isn't very
active atm and they were both the most actives developers for armv7 low
level code.

So I'm really interested in who wants to keep armv7 and why, is it
just "I'm using my RPI2 and wants to continue using it" ?

Cheers,

--
Emmanuel Vadot <ma...@bidouilliste.com> <ma...@freebsd.org>

[Poul-Henning Kamp]

--------

Emmanuel Vadot writes:

> I personnaly see armv7 in "degraded maintainance mode" since 13.0,

> So I'm really interested in who wants to keep armv7 and why, is it
> just "I'm using my RPI2 and wants to continue using it" ?

The (only) reason I personally care about 32 bit arm is the BBB's
two "PRU" co-processors and low power budget.

[John Baldwin]

I'm not sure it's accurate to say that i386 specifically hinders amd64,
it's more that 32-bit platforms in general are more limited and we
already have some features (e.g. KTLS) that only work on 64-bit platforms.
That is only going to become more true over time. We also have a finite
set of developer resources, and it's best to concentrate those on modern
commodity platforms.

> I had a much longer passage on this subject that was slated to be
> written and posted here prior to the devsummit, but the tl;dr was
> understood at the devsummit. Basically, the proposed general removal of
> 32-bit support is unfortunate but probably technically necessary.
> Investigations of certain use cases, like Wine, will need to happen to
> see how much 32-bit userland support need to remain whilst running on
> 64-bit kernel. There continue to exist production armv7 boards that
> enjoy long-term support, so removing kernel support would not only be a
> bad idea, but those who need that support the most are the least
> equipped to help on our end (unless some individuals can be nudged to
> learn).

Just because boards exist and users are interested is not sufficient reason
to keep a platform alone. We also have to have sufficient developer
interest to maintain platforms in the tree. What we learned at the summit
is there is at least still some desire for 32-bit arm systems.

--
John Baldwin

[Warner Losh]

Maybe we need to put names next to this to retain it? If there is interest it will become clear.

Althought most people use hardware to build, i still build my few packages i need with bsd-user. I can keep bsd-user going for armv7 at least for 14.. and although I have 2 armv7 boards in service today, I'd likely replace them with arm64 or riscv boards if they break either due to an update to FreeBSD not working or hardware failure.

Warner

[Peter Jeremy]

On 2023-May-24 03:49:55 +0200, Tomek CEDRO <to...@cedro.info> wrote:
>I saw that info too.. but are we going to allow Intel dictate future
>of computers and supported platforms to The FreeBSD Project?

I don't see that as the FreeBSD Project allowing Intel to dictate its
future direction but rather more exidence that chip vendors are also
deprecating 32-bit support.

>I am
>convinced that everyone will move to RISC-V pretty soon anyway :-)

Note that FreeBSD doesn't support 32-bit RISC-V

--
Peter Jeremy

[Tomek CEDRO]

On Fri, May 26, 2023 at 11:21 AM Peter Jeremy wrote:

> On 2023-May-24 03:49:55 +0200, Tomek CEDRO wrote:
> >I saw that info too.. but are we going to allow Intel dictate future
> >of computers and supported platforms to The FreeBSD Project?
> I don't see that as the FreeBSD Project allowing Intel to dictate its
> future direction but rather more exidence that chip vendors are also
> deprecating 32-bit support.
>
> >I am
> >convinced that everyone will move to RISC-V pretty soon anyway :-)
> Note that FreeBSD doesn't support 32-bit RISC-V

Thanks Peter.. I know 64-bit is now easier to maintain both in
software and hardware domain.. I just don't like "Enforced Changes
Ideologies" so things that worked well needs to be "just deleted and
replaced".. in most cases this is what destroys our current world..
its like history rewrite.. maybe marking code as "obsolete" /
"unsupported" / "abandoned" just for anyone ever wanting to play with
the code ever again rather than removing the code and leaving nothing
for the future.. I don't know what are the plans but I think code for
porting to other platforms should be preserved for various reasons
even when obsoleted it will be solid source of knowledge :-)

[John Baldwin]

git rm does not remove history. The code will always be available,
unlike issues some folks have raised with historical commerical
software that is now "dead" as the owners of that software have gone
away, etc.

But also, FreeBSD has been purging support for older things for a while
now. There are no more drivers for ISA adapters in the tree for example
including PCCard. We as a Project do not have infinite developer
resources and have to make wise decisions about where to invest those
limited resources. (See also the alpha, sun4v, ia64, sparc64, pc98, and
mips architecture support)

--
John Baldwin

[Mark Millard]

Emmanuel Vadot <manu_at_bidouilliste.com> wrote on
Date: Wed, 24 May 2023 06:35:55 UTC :

> . . .

>
> I personnaly see armv7 in "degraded maintainance mode" since 13.0,

> nothing really intersting was added, no new SoC support even if there
> was some interesting one that we could support, no new drivers for
> supported platforms. We even lost TI BeagleBone support because no one
> really have the time to keep support up to date.
> I still have some little cute boards that I want to use from time to
> time but the lack of proper porting of new language (like rust and iirc
> go have problems too) is making new software unusable on those boards
> (you can't even make some "smart speaker" for spotify as all the
> spotify clients are in rust).
> IMX6 support is stalled since ian@ passed away and mmel@ isn't very
> active atm and they were both the most actives developers for armv7 low
> level code.

One of the things for tier 2 is:
(from https://docs.freebsd.org/en/articles/committers-guide/#archs
21.4. Tier 2 section)

QUOTE
Collectively, developers are required to provide the following
to maintain the Tier 2 status of a platform:

• Tier 2 architectures must have an active ecosystem of users and developers.
END QUOTE

Is there an implication that, even for 14, the "developers"
part of that for armv7 has dropped off to the point that
tier 2 would reasonably be in question?

===
Mark Millard
marklmi at yahoo.com

[Hans Petter Selasky]

On 5/26/23 17:31, Tomek CEDRO wrote:
> Thanks Peter.. I know 64-bit is now easier to maintain both in
> software and hardware domain.. I just don't like "Enforced Changes
> Ideologies" so things that worked well needs to be "just deleted and
> replaced".. in most cases this is what destroys our current world..
> its like history rewrite.. maybe marking code as "obsolete" /
> "unsupported" / "abandoned" just for anyone ever wanting to play with
> the code ever again rather than removing the code and leaving nothing
> for the future.. I don't know what are the plans but I think code for
> porting to other platforms should be preserved for various reasons

> even when obsoleted it will be solid source of knowledge 😄

Hi,

I want to add, there are consumers of FreeBSD kernel code, like RTEMS
and QNX. If someone wants to maintain for example the Network stack for
a 32-bit platform outside of FreeBSD, how is FreeBSD thinking about
that? What is the plan there?

Instead of 128/64/32 -bit support it will be 128/64 -bit support
(thinking about CheriBSD)?

If 32-bit CPU and platform technology patents are about to expire, then
keeping 32-bit support around could be a scoop for FreeBSD, even though
32-bit PC platforms are a patchwork of technologies, going from ISA, PnP
to PCI and USB.

Citing Warner Losh:

> contains Intel's plans for the future. They have removed support for
booting 16/32-bit and non-UEFI from their firmware as of 2020...

And it is also well known how secure boot works, and allows Intel to
control who can use their hardware components or not. I would not be
surprised at all, if in the future, you would have to pay serious money
to boot FreeBSD on desktop computers. Apple has already been doing this
for many years.

Given secure booting is not defined for 32-bit platforms, is this a
strong argument to keep 32-bit support around?

Personally I would see it as a big step backwards to boot up Windows or
Apple first, then run VirtualBox or VMware, and then login to FreeBSD.
Not only would it require you to constantly pull system updates for two
systems, but it will totally screw performance.

--HPS

[Hans Petter Selasky]

On 5/30/23 16:36, Hans Petter Selasky wrote:
> Personally I would see it as a big step backwards to boot up Windows or
> Apple first, then run VirtualBox or VMware, and then login to FreeBSD.
> Not only would it require you to constantly pull system updates for two
> systems, but it will totally screw performance.

.... USA is officially sanctioning Huawei. But still yet devices using
the USB ID for Huawei are being enumerated just fine. I'm glad the world
leaders today are of the age they are, and the bureaucrats below them
know nothing about the weapons they possess and what damage they may
actually do to the world! Not only do they want to bomb people to death.
They want to delete their history, their names, their data, their
products, everything. If there is no data, no name, no history. There
was no war either.

--HPS

[John Baldwin]

On 5/30/23 7:36 AM, Hans Petter Selasky wrote:
> On 5/26/23 17:31, Tomek CEDRO wrote:
>> Thanks Peter.. I know 64-bit is now easier to maintain both in
>> software and hardware domain.. I just don't like "Enforced Changes
>> Ideologies" so things that worked well needs to be "just deleted and
>> replaced".. in most cases this is what destroys our current world..
>> its like history rewrite.. maybe marking code as "obsolete" /
>> "unsupported" / "abandoned" just for anyone ever wanting to play with
>> the code ever again rather than removing the code and leaving nothing
>> for the future.. I don't know what are the plans but I think code for
>> porting to other platforms should be preserved for various reasons
>> even when obsoleted it will be solid source of knowledge 😄
>
> Hi,
>
> I want to add, there are consumers of FreeBSD kernel code, like RTEMS
> and QNX. If someone wants to maintain for example the Network stack for
> a 32-bit platform outside of FreeBSD, how is FreeBSD thinking about
> that? What is the plan there?

Folks are more than welcome to use bits of FreeBSD in their own codebases,
but FreeBSD is not obligated to maintain those bits in other codebases.
The healthy relationship there is for those consumers to engage with their
upstream (FreeBSD).

> Instead of 128/64/32 -bit support it will be 128/64 -bit support
> (thinking about CheriBSD)?

CHERI is not full 128-bit integers (e.g. long and addresses are still
64-bits), so it's not quite as large a gap as 32 vs 64 (though is close).

> If 32-bit CPU and platform technology patents are about to expire, then
> keeping 32-bit support around could be a scoop for FreeBSD, even though
> 32-bit PC platforms are a patchwork of technologies, going from ISA, PnP
> to PCI and USB.

MIPS patents are expired and we removed that, too. The code is also not
going away, but the question is what is our consensus as a project on where
we want to focus our efforts.

--
John Baldwin

[Mike Karels]

On 30 May 2023, at 12:55, John Baldwin wrote:

> On 5/30/23 7:36 AM, Hans Petter Selasky wrote:

>> ...

>> I want to add, there are consumers of FreeBSD kernel code, like RTEMS
>> and QNX. If someone wants to maintain for example the Network stack for
>> a 32-bit platform outside of FreeBSD, how is FreeBSD thinking about
>> that? What is the plan there?
>
> Folks are more than welcome to use bits of FreeBSD in their own codebases,
> but FreeBSD is not obligated to maintain those bits in other codebases.
> The healthy relationship there is for those consumers to engage with their
> upstream (FreeBSD).
>
>> Instead of 128/64/32 -bit support it will be 128/64 -bit support
>> (thinking about CheriBSD)?
>
> CHERI is not full 128-bit integers (e.g. long and addresses are still
> 64-bits), so it's not quite as large a gap as 32 vs 64 (though is close).

One advantage of having at least one 32-bit system as part of the build
is that it finds mismatched/non-portable use of integer types and format
strings. If there is no real 32-bit platform worth updating, maybe we
could include a “null” 32-bit port, e.g. one without machine-dependent
code other than headers? It could be based on i386 or armv7, but obviously
would not include a full kernel. It could potentially include stubs to
allow the kernel to link, but just generating object files for the MI
parts would be valuable. Does anyone have any idea how much work this
might be? If we have the ability to build 32-bit user-level binaries
with -m32, the kernel or kernel objects would be the main addition.

Mike

[Tomek CEDRO]

On Wed, May 31, 2023 at 6:12 AM Hans Petter Selasky wrote:
> (..) I'm glad the world

> leaders today are of the age they are, and the bureaucrats below them
> know nothing about the weapons they possess and what damage they may
> actually do to the world! Not only do they want to bomb people to death.
> They want to delete their history, their names, their data, their
> products, everything. If there is no data, no name, no history. There
> was no war either.

Exactly, history rewrite, and people does not even seem to care o_O

[Warner Losh]

For the 14 branch, armv7 seems to be right on the edge. Some

bugs do get fixed, but some of the SoCs are so poorly maintained

that they don't work anymore (for whatever reason). So "degraded

maintenance mode" is likely apt for 14: it will still work, mostly, but

many cool new things that people want, both in terms of languages

and new hardware support will be lacking in some way, shape or

form. Tier 2 is likely still the best tier to keep it at, imho. 

Warner

[Mark Millard]

One thing I was unsure of is how much the choice is driven
by things as they are at around releng/14.0 vs. what things
might be expected to be like around, say, releng/14.4 (a
number of years later). It appears that changing tier status
is normally avoided for the likes of 14.[1-4] .

[Warner Losh]

A lot of it is sticking your finger in the air and projecting out 4 years. If nobody is going to be making any fixes and the code doesn't work at that point, we are better off killing it now. For armv7, I still see bug fixes happening, but anticipate that any bad bug that pops up may not het fixed. I see no new hardware support absent some unforeseen resurgence. 

I suspect when we branch 15, it's 4 years out prospects will be even worse. But I don't know that for sure.

Warner

[Cy Schubert]

IMO, having to "double back" to fix format errors or integer conversion errors causes developers just that little bit of distraction, time that added up over time could be put to better use elsewhere. Compilers tend to be more fussy these days, meaning one must pay even more attention to 64-bit vs 32-bit than before. That's been my take over the years.


--
Cheers,
Cy Schubert <Cy.Sc...@cschubert.com>
FreeBSD UNIX: <c...@FreeBSD.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
e^(i*pi)+1=0

Pardon the typos. Small keyboard in use.

[John Baldwin]

I've posted a couple of reviews to add a WARNING to dmesg during the boot
of 32-bit kernels as well as to add a note to RELNOTES to serve as the
starting point for the note in the release notes:

https://reviews.freebsd.org/D41163
https://reviews.freebsd.org/D41164

Also, Mike Karels has been working on lib32 support for aarch64 that should
be included in 14.0.

--
John Baldwin

[Mark Millard]

John Baldwin <jhb_at_FreeBSD.org> wrote on
Date: Mon, 24 Jul 2023 19:33:57 UTC :

I see no wording about armv6 being removed earlier.

At one time Warner had written:

>> On Tue, Dec 13, 2022 at 11:48 AM Mark Millard <mar...@yahoo.com> wrote:
>> FYI: The old 2021-Oct-28 message related to armv6 removal
>> sequencing/timing has a new follow up finally:
>>
>> https://lists.freebsd.org/archives/freebsd-arch/2022-December/000313.html
>>
>> (Nothing about this changes the armv7 status.)
>
> Nope.
>
> tl;dr: armv6 packages will stop, we'll stop doing -current armv6 snapshots, we'll move armv6 to
> an 'extra' architecture in universe for stable/14. post stable/14 we'll tear down support for armv6
> in base and later in ports. Ports mention armv6 ~500 times, maybe 1/4 of them also mention armv7,
> and the vast majority of them mark things as broken in some way (though there are exceptions).

[Warner Losh]

I'm still hoping to get to this... I think it's the last time on my 'wanna get done before 14' checklist. It

is orthogonal to the 32-bit stuff.

Warner

[sh...@freebsd.org]

I realize I'm late to the party, but I just posted this:
https://reviews.freebsd.org/D41201 which led to me discovering this
thread.

The reason I did this was because I need to hack up a thing to go
between the internet and a 1984 vintage computer with a 111,840bps
serial port, and I want to integrate a supercap UPS into the design.

Initially, I had thought to just use Linux on the device since it came
with it, but for some reason, Linux couldn't receive at 111840 without
dropping characters.  The Z80 system in question doesn't have flow
control, so rather than fight with Linux, I decided to fight with
something I like.  As it happens, FreeBSD has no issue with the serial
port.

So what's left that I'll need for my project is getting the ADC driver
usable (it doesn't look like it's exposed outside of the kernel
currently) to monitor/control the supercap UPS hardware.  I grabbed a
few of these boards since they're so cheap ($20 each), so I'll likely be
using more of them for various things.

Doing the same development using NetBSD or OpenBSD would be a bit more
painful since I'm running FreeBSD on all my systems, am familiar with
building and installing it, and have the source laying around
everywhere.

I was actually quite surprised that there's packages available, but I'm
not sure I would understand what a statement that we may not support
them in 15 would actually mean.  armv7 is already Tier 2, which is
explicitly not supported by secteam, releng, and ports.  If that just
means moving it to Tier 3, that wouldn't bother me much, though I'm not
sure how often universe fails because of it due to something that
doesn't need to be fixed anyway.  If it means open season on deleting
any armv7-specific "stuff" you happen across, it would bother me, and if
it means someone taking a couple days to find all the armv7 stuff and
removing it, it would feel spiteful.

If armv7 is actually causing universe to fail in weird arm-specific ways
that actually distract Tier 1 developers with irrelevant minutia, a move
to Tier 3 is clearly warranted.  Maybe I just don't understand how much
effort is being wasted on the level of support armv7 is currently
getting.

TL:DR: I want to keep armv7 because you can still do some cool things
with it, but I don't insist anyone else do work beyond not breaking
universe to keep it running (and if not breaking universe is a problem,
I don't even insist on that).

[John Baldwin]

It's not just about make tinderbox, it is also about keeping platforms
viable. One big example is that we probably need to start supporting the
use of rust in the base system in some form in the not too distant
future, but rust isn't supported on armv7 on FreeBSD (and someone would
need to do the work to make that happen). This is already starting to be
a problem in ports because some 3rd party software (like py-cryptography)
is requiring rust for modern versions, but we are currently holding that
port back to cater to armv7. Platforms have to have enough active
developers supporting them to remain viable.

--
John Baldwin

[sh...@freebsd.org]

Yeah, Rust-in-base would certainly be an excellent reason to drop platforms
without Rust support to Tier 3 at best.

I guess my confusion is simply that I thought that it being Tier 2 was
already
a public statement that "we may remove them outright from the tree, or we

[Mark Millard]

John Baldwin <jhb_at_FreeBSD.org> wrote on

Date: Thu, 03 Aug 2023 19:57:08 UTC :

> On 7/27/23 10:49 AM, sh...@FreeBSD.org wrote:
> > On 2023-05-24 01:35, Emmanuel Vadot wrote:
> >> On Tue, 23 May 2023 16:46:51 -0700
> >> John Baldwin <j...@FreeBSD.org> wrote:
> >>
> >>> On 4/27/23 10:19 AM, John Baldwin wrote:

> >>>> . . .

>
> It's not just about make tinderbox, it is also about keeping platforms
> viable. One big example is that we probably need to start supporting the
> use of rust in the base system in some form in the not too distant
> future, but rust isn't supported on armv7 on FreeBSD (and someone would
> need to do the work to make that happen).

I'm confused about the "isn't supported on armv7 on FreeBSD"
claim:

# pkg info rust
rust-1.70.0_1
Name : rust
Version : 1.70.0_1
Installed on : Sun Jul 16 21:37:58 2023 PDT
Origin : lang/rust
Architecture : FreeBSD:14:armv7
Prefix : /usr/local
Categories : lang
Licenses : MIT or APACHE20
Maintainer : ru...@FreeBSD.org
WWW : https://www.rust-lang.org/
Comment : Language with a focus on memory safety and concurrency
Options :
DOCS : on
GDB : off
SOURCES : on
WASM : on
Shared Libs required:
libcurl.so.4
Annotations :
FreeBSD_version: 1400093
build_timestamp: 2023-07-16T00:27:00+0000
built_by : poudriere-git-3.3.99.20220831
cpe : cpe:2.3:a:rust-lang:rust:1.70.0:::::freebsd14:armv7:1
port_checkout_unclean: no
port_git_hash : 8bcbc1e32c6c
ports_top_checkout_unclean: yes
ports_top_git_hash: f1271d14fb6f
repo_type : binary
repository : custom
Flat size : 1.08GiB
Description :
Rust is an open-source systems programming language that runs blazingly
fast, prevents almost all crashes, and eliminates data races.
Some of its features:

- Algebraic data types, type inference
- Pattern matching and closures
- Concurrency without data races
- Guaranteed memory safety
- Optional garbage collection
- Zero-cost abstractions
- Minimal runtime
- Efficient C bindings

WWW: https://www.rust-lang.org/

That is my own poudriere=devel style build but the 2023-Jul-27:

http://ampere2.nyi.freebsd.org/data/main-armv7-default/pe5b71726cc79_s92fd2f39e5/logs/rust-1.71.0.log

is a log for a successful official build of a more recent version
than my last build.

Is it really some things that use/need rust that are the problem,
not the rust port itself? If yes, could you be more specific?

> This is already starting to be
> a problem in ports because some 3rd party software (like py-cryptography)
> is requiring rust for modern versions, but we are currently holding that
> port back to cater to armv7. Platforms have to have enough active
> developers supporting them to remain viable.

[John Baldwin]

On 8/3/23 2:36 PM, Mark Millard wrote:
> John Baldwin <jhb_at_FreeBSD.org> wrote on
> Date: Thu, 03 Aug 2023 19:57:08 UTC :
>
>> On 7/27/23 10:49 AM, sh...@FreeBSD.org wrote:
>>> On 2023-05-24 01:35, Emmanuel Vadot wrote:
>>>> On Tue, 23 May 2023 16:46:51 -0700
>>>> John Baldwin <j...@FreeBSD.org> wrote:
>>>>
>>>>> On 4/27/23 10:19 AM, John Baldwin wrote:
>>>>>> . . .
>>
>> It's not just about make tinderbox, it is also about keeping platforms
>> viable. One big example is that we probably need to start supporting the
>> use of rust in the base system in some form in the not too distant
>> future, but rust isn't supported on armv7 on FreeBSD (and someone would
>> need to do the work to make that happen).
>
> I'm confused about the "isn't supported on armv7 on FreeBSD"
> claim:

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853
as an example. According to that bug at least rustc is not doable
under qemu-user which is how armv7 packages are built.

--
John Baldwin

[Kyle Evans]

To be clear, that really only matters for user builds. bsd-user has been
replaced in all official builders, as far as I'm aware, and official
armv7 packages are done with COMPAT32 on an arm64 boxen.

Thanks,

Kyle Evans

[Warner Losh]

I'l need to test this again. A number of interesting bugs have been fixed

in upstream.

Also, I thought we'd shifted building armv7 packages on an aarch64

server that can runs 32-bit jails...

Warner

[Mark Millard]

Are folks confusing armv6 vs. armv7? armv6 ports are still built into
packages via qemu.

But official armv7 port builds are done on aarch64 in poudriere(-devel?)
armv7 jails, without use of qemu. The ampere[123] build servers support
aarch32/armv7 native execution and that is put to use in the last year.

https://pkg-status.freebsd.org/?all=1&type=package reports the first ampere
armv7 build as:

default default 130releng-armv7 a51002eeb3d0 32299 29273 294 1791 941 0 stopped:done: Fri, 22 Jul 2022 07:39:45 GMT 66:37:20 ampere3

The first build of armv7 main:

default default main-armv7 p83aeeda2ebb7_s30253da1a 32288 29099 (+27041) 274 (+147) 1948 (+26) 967 (+247) 0 stopped:done: Fri, 29 Jul 2022 21:46:08 GMT 88:40:40 ampere2

The first build of armv7 quarterly:

default quarterly 130releng-armv7 8662e656d870 32236 29152 (+27142) 238 (+140) 1871 (+9) 975 (+237) 0 stopped:done: Fri, 05 Aug 2022 13:04:55 GMT 70:00:06 ampere1

(I've been building armv7 ports that way for longer, but on different
hardware.)

[Robert Clausecker]

Hi John,

It builds natively just fine. This is a problem with qemu-user, not
rust.

Yours,
Robert Clausecker

> --
> John Baldwin
>
>

--
() ascii ribbon campaign - for an 8-bit clean world
/\ - against html email - against proprietary attachments

[Ed Maste]

On Wed, 24 May 2023 at 02:53, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote:
>
> The (only) reason I personally care about 32 bit arm is the BBB's
> two "PRU" co-processors and low power budget.

It's likely too late for BBB already, it was removed from GENERIC in
3416e102c4e9.

[Warner Losh]

Yea... of course if someone updates its drivers for the evolution of the dts "standards" it could come back. Likely only a few days worth of tedious archeological digs into the linux kernel to see what changed... but so far nobody has stepped up to the relatively simple, but also tedious work.  

Warner

[Brooks Davis]

We've been using BBBs with (IIRC) 13.x images to access USB management bits
(8 FDTI links and one umass device) on Morello development boards. To
say it's a frustrating experience would be an understatement. We're in
the process[0] of giving up and switching to Linux. It's not entirely
clear why things have rotted so badly, but they have.

I suspect consumer embedded boards tend to be deploy-and-forget so
we're just not seeing enough new installs to keep things working.

-- Brooks

[0] It's a project because we're having to swap micro SD cards in BBBs
inside 20+ servers in a data center with restrictive access controls.