Re: What's the plan for powerpc64 in FreeBSD 16

On Tue, Nov 18, 2025 at 04:12:15AM -0600, Timothy Pearson wrote:
> 
> 
> ----- Original Message -----
> > From: "Konstantin Belousov" <kostikbel@gmail.com>
> > To: "Timothy Pearson" <tpearson@raptorengineering.com>
> > Cc: "Warner Losh" <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>
> > Sent: Tuesday, November 18, 2025 4:09:41 AM
> > Subject: Re: What's the plan for powerpc64 in FreeBSD 16
> 
> > On Tue, Nov 18, 2025 at 03:22:17AM -0600, Timothy Pearson wrote:
> >> 
> >> 
> >> ----- Original Message -----
> >> > From: "Timothy Pearson" <tpearson@raptorengineeringinc.com>
> >> > To: "Warner Losh" <imp@bsdimp.com>, "freebsd-arch@freebsd.org"
> >> > <arch@freebsd.org>
> >> > Sent: Tuesday, November 18, 2025 3:13:05 AM
> >> > Subject: Re: What's the plan for powerpc64 in FreeBSD 16
> >> 
> >> > On 11/17/25 10:57, Warner Losh wrote:
> >> >> Greetings,
> >> >>
> >> >> As we're getting close to the release date for FreeBSD 15.0, it's time
> >> >> to take stock of another architectures. This time, I'd like your
> >> >> feedback on the following plans.
> >> >>
> >> >> We'd like to retire powerpc64 and powerpc64le just before the FreeBSD
> >> >> stable/16 branch.
> >> >>
> >> >> This would give powerpc64 another two years of support in main,
> >> >> followed by sustaining support on stable/14 and stable/15 until
> >> >> the end of those branches.
> >> >>
> >> >> We've come to this point because the port is dwindling and we have a
> >> >> cost associated with keeping it around. The number of developers has
> >> >> fallen off so only a couple remain. Issues in powerpc are taking
> >> >> longer and longer to discover and resolve. The hardware has been a
> >> >> huge source of frustration for clusteradmin and we've no alternative
> >> >> for developers. There's only a tiny user base. We have trouble
> >> >> building packages for it. Also, powerpc has a number of interesting
> >> >> features of the architecture that make it the odd arch out.
> >> >>
> >> >> It's also big endian. While that may seem like a reason to keep it
> >> >> around, if we really can't support it and we're not actively testing
> >> >> functionality of the system, then keeping this around actually doesn't
> >> >> help keep us honest. It just gives us a burden we must bear.
> >> >>
> >> >> In my opinion, powerpc64 appears to have already fallen below critical
> >> >> mass, despite being a sentimental favorite for a number of FreeBSD
> >> >> developers. As such, I'd like us to consider planning to retire it
> >> >> before we branch 16.
> >> >>
> >> >> My questions today: Are you using this port? How many people are using
> >> >> it? And what's the installed base? It appears to be somewhat less than
> >> >> that of either i386 or armv7 based on user surveys and popularity at
> >> >> conferences. Also, any other comments you might have.
> >> >>
> >> >> Warner
> >> > 
> >> > We are very much using this port on a number of machines, and have plans
> >> > to expand further.  We use the powerpc64le port in critical
> >> > infrastructure applications.
> >> > 
> >> > While we do not participate in the user surveys for security reasons,
> >> > and many other POWER users may be in a similar situation, I would like
> >> > to offer an alternate means of gauging powerpc64le (as opposed to
> >> > powerpc big endian) via the Debian popularity contest [1].  This clearly
> >> > shows the decline in powerpc64 but also the increase in powerpc64le
> >> > installs -- in fact, at least according to those statistics, powerpc64le
> >> > is about to overtake armel in terms of overall deployment base.
> >> > 
> >> > Raptor remains committed to the architecture as a whole, and we have
> >> > resources to assist with development.  In fact, we sponsor several
> >> > FreeBSD build machines already in our cloud environment, and have kernel
> >> > developers working on expanding and maintaining the FreeBSD codebase.
> >> > If there is any concern regarding hardware availability or developer
> >> > resources, Raptor is willing and able to assist.
> >> > 
> >> > Finally, I do want to point out that this is the only open server-grade
> >> > ISA in existence.  This is the main reason Raptor selected it in the
> >> > first place, and why Raptor has remained committed to its overall
> >> > support and containment.  As we continue porting to e.g. Xen and other
> >> > operating systems, I would hope that we can reach a point where at least
> >> > the powerpc64le support is not only maintained but is able to be
> >> > promoted to a higher status within FreeBSD.
> >> > 
> >> > Thank you!
> >> > 
> >> > [1] https://popcon.debian.org/
> >> 
> >> I also wanted to add, I know we had a rough time getting our patches merged into
> >> the FreeBSD tree in the past, but you can see recent activity on e.g. in-kernel
> >> AES support.  This is a direct result of our use case and we do not see any
> >> alternative architecture on the horizon that will meet both the self-sovereign
> >> and performance requirements of not only our application, but many similar
> >> applications with the EU.
> >> 
> >> If it helps, I'm willing to step up as a maintainer and make sure that at least
> >> powerpc64le does not block the release process.  In terms of my credentials in
> >> this area, I have been maintaining the powerpc64le port of Chromium for many
> >> years, on a far faster release cadence than FreeBSD; I don't foresee any major
> >> difficulties in keeping the architecture up to date.
> >> 
> > 
> > Can we please, as the part of the commitment for the ppc support, have
> > a patch submitted for the rtld wart fix?
> > I mean, we should have properly architectured hook for ppc64 to do the
> > hack in libexec/rtld-elf/rtld.c under the #ifdef powerpc, for auxv
> > renumbering compat.
> 
> I don't see why not.  This is exactly the reason we have FTE resources assigned to maintain the software ecosystem for ppc64 -- if there are any other such issues just let me know and I'll make sure they get fixed.

Great.
In fact, I went ahead and drafted the change I want, in
https://reviews.freebsd.org/D53801

I am not sure if this is needed for both ppc and ppc64/ppc64le.
Also I did not handled other arches until ppc part is finalized.

Could you please get somebody answer the question above, and then
have the patch tested, please?