Date: Tue, 18 Nov 2025 04:12:15 -0600 (CST) From: Timothy Pearson <tpearson@raptorengineering.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: <1827088521.116443.1763460735444.JavaMail.zimbra@raptorengineeringinc.com> In-Reply-To: <aRxF5b9HIBKw3h8D@kib.kiev.ua> References: <1795409779.114152.1763457185418.JavaMail.zimbra@raptorengineeringinc.com> <875004641.116392.1763457737172.JavaMail.zimbra@raptorengineeringinc.com> <aRxF5b9HIBKw3h8D@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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. Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1827088521.116443.1763460735444.JavaMail.zimbra>