Re: What's the plan for powerpc64 in FreeBSD 16
Adrian Chadd <[email protected]> Sat, 22 Nov 2025 12:30:26 -0800
| Newsgroups | gmane.os.freebsd.architechture |
|---|---|
| Message-ID | <CAJ-Vmokqtb7f0vx9G2j+zuZikzHmgsmkB_R4FtRP-7rwk4Yykw@mail.gmail.com> |
On Mon, 17 Nov 2025 at 08:58, Warner Losh <[email protected]> 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. > > fwiw, I've ordered a couple of older SMP powerpc64 (ie big endian) devices to fix some long standing bugs on with @jhibbits. They don't look too hard (timekeeping stuff in SMP) and since there's been people asking about it, I figure why not. Honestly I think it's worth having ppc64 be around just to remain big endian compliant. It's not exactly hard to find the old hardware, the power8/power9 stuff lets you choose your endian-ness in each VM so we don't need old hardware to keep it clean, and I like the idea of keeping things honest. What I do however think is worth asking is whether we start thinking about "not everything" ports builds for these platforms. eg, if chromium, firefox, rust, go, etc aren't going to work out of the box then ok, they won't be running a moden GUI without google / mozilla accepting more big-endian port diffs, but that doesn't mean we shouldn't build a subset of ports. (and maybe it's also time to have the meta meta discussion of "what's the base set of ports we should always try building that guarantees we can do SOME development (like git, rsync, shells, autotools, gdb/kgdb (yes because we still require kgdb for coredumps to work, but it's not in the tree, sigh), some compiler subset, etc.) -adrian