Hector Martin

Meanwhile, seeing what @marcan42 just did... Having a Mach-O header present through a linker script for an _ELF_ linker is… let’s say quite unique.

This is a Linux bootloader, why would I force people to get a mach-o toolchain to compile it? That would be silly, when mach-o is just being used as a completely unnecessary wrapper format for what should have been a simple bare-metal binary blob.

Hmmm? There are very good reasons for it to be a Mach-O, mainly the thing that it’s the macOS kernel loading path. Are you advocating for kernelcaches to be flat files? And for compiling Mach-Os, you just need clang and lld installed on the system, shouldn’t be a big hurdle.

Linux ARM64 kernels are flat files even though Linux is an ELF system :-) clang "shouldn't be a big hurdle" but it's a bigger hurdle than the aarch64-linux-gnu-gcc that every person compiling anything on arm64 linux already has available.

The reason why OS kernels don't need to be full-fat executable formats is that they only need a tiny fraction of the features of such formats. As far as I can tell the only reason for Darwin to be using mach-o is so iBoot can preconfigure some KTRR stuff.

Much more than that, it’s that the kernel cache is a bundle with the kernel extensions included too.

Those kexts are prelinked into one text blob these days though, which at that point isn't unlike Linux's built-in kernel modules. Linux uses tons of internal sections to implement stuff like that, but none of it needs to be visible at the bootloader ABI level.

Similarly Linux can include bare modules in a built-in initramfs, but again, the bootloader doesn't care about that (though it can supply one but that's not the only way to do it).