I'm leaning toward @jrtc27's side of things here, but I would like to know more about the issues that were seen that prompted adding this code in the first place. Worst case is that the code being reverted "fixed" the original issue by simply modifying timing / avoiding a race condition, especially given that a.) we tend to have a lot more cores than the other two weak memory ordering architectures and b.) they don't have this kind of flushing behavior yet apparently function normally.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Fri, Jan 16
Dec 15 2025
Dec 3 2025
Merged as 201af1a14
Nov 19 2025
In D53801#1229373, @pkubaj wrote:One note from a ports maintainer perspective: rust currently uses FreeBSD 11 syscalls. Although those are new binaries, they need COMPAT_FREEBSD11, even for powerpc64le (which was introduced in 13.0). There is long-going plan to bump that to 12, but even then we'll still need COMPAT_FREEBSD12.
Another thing: dropping support for running old binaries (as in compiled long ago) is not an issue for me (and probably most users), but then ELFv1 support should probably also be dropped. We switched to ELFv2 in 13.0.
In D53801#1229366, @brooks wrote:In D53801#1229342, @kib wrote:After thinking about this code some more, I realized that it probably should be removed altogether. Basically, it is there to allow to run newer binaries (rtld/libsys) on older (pre-AT_ renumbering) kernels. This was done in ~2019, and arguably outlived even the limited usefulness it had at the time of the commit.
I'm not sure this analysis is entirely correct. __elfN(powerpc_copyout_auxargs) will use the old numbering if the binary is old (but not so old it doesn't have an OSREL embedded). What I'm not sure about is if this will happen with a new rtld and old binary or just with an old static binary.
That being said I'd like both bits to go away if possible. @tpearson_raptorengineering.com how important to you think old binary support is to the powerpc64 community?
On second read through, caught a couple of code issues that don't affect functionality. Once those are fixed this looks good.
Looks good to me on a POWER9 Blackbird / powerpc64le.
Sep 11 2025
In D52400#1198743, @markj wrote:I just went ahead and uploaded an extended diff, I hope that's ok: https://reviews.freebsd.org/D52490
Sep 10 2025
Added aesni and armv8crypto alongside ossl
Sep 5 2025
In D44274#1185321, @pkubaj wrote:@shawn_anastas.io
FYI, OpenSSL 3.5 has been merged, so you should probably rebase this review. I hope it can finally be pushed before stable/15.
Rebase for 15.0
Jun 29 2025
@jhibbits I'm wondering the same thing. On my side this seems good, any chance we can get it merged? Raptor is still carrying this as a downstream patch in its OPNsense builds. Thanks!