Date: Tue, 18 Nov 2025 13:11:39 +0200 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> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: <aRxUa5u1ZKrTTt1b@kib.kiev.ua> In-Reply-To: <1827088521.116443.1763460735444.JavaMail.zimbra@raptorengineeringinc.com> References: <1795409779.114152.1763457185418.JavaMail.zimbra@raptorengineeringinc.com> <875004641.116392.1763457737172.JavaMail.zimbra@raptorengineeringinc.com> <aRxF5b9HIBKw3h8D@kib.kiev.ua> <1827088521.116443.1763460735444.JavaMail.zimbra@raptorengineeringinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aRxUa5u1ZKrTTt1b>