I think these are good. There's comments in the Linux emulator that says they do different things because of this ifdef:
compat/linux/linux_misc.c: * td->td_retval when COMPAT_43 is defined. This clobbers registers that
compat/linux/linux_uid16.c: * when COMPAT_43 is defined. This clobbers registers that are assumed to
maybe that means there can be a simplification?
I think a related question on the mail thread was if COMPAT_43 should be in any non-x86 config files at all. E.g. it shouldn't be in sys/conf/notes but should move to sys/x86/conf/NOTES once we start that.
Let's see, these changes would mean COMPAT_43 is just a normal 'include old code' stuff.
sparc64 wouldn't need it, since it didn't do a.out But it's frankly irrelevant...
powerpc I'm unsure about, but I don't think it needs it, despite it being in several kernels
powerpc64 I'm pretty sure doesn't need it since it doesn't support a.out.
mips doesn't need it since binary compatibility has been busted several times and we've never supported a.out.
I'm pretty sure it's close to a no op on 32-bit arm. There's no really old binaries that matter: we broke compatibility with EABI changes, and then again with the move to v6/v7, so compat for anything before FreeBSD 9 (or was it 10) is a don't care.
arm64 doesn't need it if arm doesn't need it.
riscv doesn't need it since it's too new.
I'd be willing to do the legwork unless kib@ knows some reason you and I are overlooking.
The comments are partially outdated. They provide motivation why these syscalls needed a linuxolator reimplementation initially, but now there are much more serious reasons to have them in linuxolator, e.g. tid support. I removed the comments altogether, they only accumulated the confusion over the time.
a.out was only supported on i386, and then was ported to amd64 to only have an ability to run i386 a.out on modern hardware. I think all other arches never ever had FreeBSD a.out support at all, so COMPAT_43 for them, after this patch lands, would mean the additional set of obsolete syscalls provided. I think that we can axe COMPAT_43 from the corresponding kernel configs safely, as a followup to this review.