From nobody Tue Nov 18 11:11:39 2025 X-Original-To: arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d9hlH4PMpz6Gwhv for ; Tue, 18 Nov 2025 11:11:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4d9hlH0BR0z3WHc for ; Tue, 18 Nov 2025 11:11:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5AIBBdkn024115; Tue, 18 Nov 2025 13:11:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5AIBBdkn024115 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5AIBBd79024114; Tue, 18 Nov 2025 13:11:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Nov 2025 13:11:39 +0200 From: Konstantin Belousov To: Timothy Pearson Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: References: <1795409779.114152.1763457185418.JavaMail.zimbra@raptorengineeringinc.com> <875004641.116392.1763457737172.JavaMail.zimbra@raptorengineeringinc.com> <1827088521.116443.1763460735444.JavaMail.zimbra@raptorengineeringinc.com> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1827088521.116443.1763460735444.JavaMail.zimbra@raptorengineeringinc.com> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d9hlH0BR0z3WHc On Tue, Nov 18, 2025 at 04:12:15AM -0600, Timothy Pearson wrote: > > > ----- Original Message ----- > > From: "Konstantin Belousov" > > To: "Timothy Pearson" > > Cc: "Warner Losh" , "freebsd-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" > >> > To: "Warner Losh" , "freebsd-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?