Make COMPAT_FREEBSD32 part of GENERIC on arm64.

[ed]

Summary

The cloudabi32.ko kernel modules can only be loaded on AMD64 and ARM64
by kernels built with COMPAT_FREEBSD32. Even though COMPAT_FREEBSD32
does not support the execution of native FreeBSD executables, do add it
to GENERIC, to make cloudabi32.ko usable.

According to size(1), this makes the kernel image approximately 0.7%
larger.

[imp]

Well, if it was 0.8% larger, I'd have my pitch-pots and feather bags lined up, but for only 0.7%, I'm good.

[andrew]

sys/arm64/conf/GENERIC

55

Should there be a comment that this only works with CloudABI?

[ed]

Use a different description that fits within 80 columns.

[ed]

sys/arm64/conf/GENERIC

55

Sure. What do you think about this description?

[emaste]

Description looks good.

Question, what happens on hardware w/o AArch32?

[andrew]

In D13311#278098, @emaste wrote:

Description looks good.

Question, what happens on hardware w/o AArch32?

You'll probably get an exception on the first instruction.

A simple way would be to set a flag in identcpu.c under the ID_AA64PFR0_EL0 case to signal no 32-bit support if any CPUs lack it. This could then be queried in the exec path & complain to the user if it's unable to be run. We can test on ThunderX as it only supports AArch64.

[ed]

Hi Andrew,

In D13311#278604, @andrew wrote:

Question, what happens on hardware w/o AArch32?

You'll probably get an exception on the first instruction.

A simple way would be to set a flag in identcpu.c under the ID_AA64PFR0_EL0 case to signal no 32-bit support if any CPUs lack it. This could then be queried in the exec path & complain to the user if it's unable to be run. We can test on ThunderX as it only supports AArch64.

Good point. The existing cloudabi32.ko doesn't do anything with that at all. Would it make sense to let the modload fail in case the CPU doesn't support it?