Correct reporting of compat32 support to userspace

[kib]

Summary

sysctl kern.supported_archs: return correct value

in case COMPAT_FREEBSD32 was enabled in config but hardware does not
support executing 32bit binaries.

FEATURE compat_freebsd_32bit: only report on arm64 when support is present

depending on hardware support for aarch32.

Tweak compat_freebsd32_bit feature name

Mark the current name 'compat_freebsd_32bit' as legacy, and add the
new name 'compat_freebsd32'.  This seems to help with some make and
shell uses.

[kib]

Fix to not report feature at all, instead of registering oid with zero value.

[jrtc27]

sys/compat/freebsd32/freebsd32_misc.c

126 ↗

(On Diff #130287)

Can we take the opportunity to align this name with everything else, ie just call it compat_freebsd32? That way you have compat_freebsdX as a feature that corresponds to ldconfig -X for ld-elfX.so.1 using libX built by MK_LIB${X:U}

[kib]

sys/compat/freebsd32/freebsd32_misc.c

126 ↗

(On Diff #130287)

But then what about FreeBSD 32.x? Do you think that FreeBSD would not survive that long, that compat32 support would be irrelevant, or that we skip this version number?

[jrtc27]

sys/compat/freebsd32/freebsd32_misc.c

126 ↗

(On Diff #130287)

It’s 36 years away, I really hope that 32-bit has died by 2055…

But that problem already exists today; e.g. we call it COMPAT_FREEBSD32 in the build system, which is in the same namespace as COMPAT_FREEBSD14. Like it or not, freebsd32 is its name.

[jrtc27]

sys/compat/freebsd32/freebsd32_misc.c

126 ↗

(On Diff #130287)

Uh 2058 even, my head swapped it to 32 years

[jrtc27]

sys/compat/freebsd32/freebsd32_misc.c

126 ↗

(On Diff #130287)

2059… not awake it seems

[kib]

compat_freebsd32 name

[markj]

sys/compat/freebsd32/freebsd32_misc.c

134 ↗

(On Diff #130307)

This should really be hidden with a macro, FEATURE_ADD() perhaps.

[kib]

FEATURE_ADD()

[emaste]

e.g. we call it COMPAT_FREEBSD32 in the build system, which is in the same namespace as COMPAT_FREEBSD14

That is true, but that conflict could be addressed in the future (by renaming the option to COMPAT_FREEBSD_32BIT, say) with minimal backwards compatibility concern or user-visible impact.