On 2025-06-15, Leo Famulari wrote: > On Sun, Jun 15, 2025, at 07:29, Efraim Flashner wrote: >> As the owner of several aarch64 and riscv64 machines, I can tell you >> that if they are running Guix System then I have them using the -generic >> kernel. > > Thanks for chiming in! > > This is basically the only feedback I get about these non-Intel > platforms. Please give an opinion: should we retire the non-generic > kernels for these platforms?
I have definnitely used the "linux-libre" (e.g. non-generic) kernel in the past on arm64 (and in the distant past, armhf), though the machines I used it on are out of commission due to various hardware failures. I think the "full" kernel makes sense in some cases, and the "generic" or board-specific kernels make sense in others. e.g. the "full" kernel works reasonably well in a virtual machine. e.g. the "full" kernel would probably be a reasonable target for an aarch64-linux installer image targeting EFI boot, where making a separate installer image for each and every available arm platform would result in a huge proliferation of images and eat a lot of build farm resources to generate images that are 95-99% identical. e.g. I am currently working on fixing the build for the linux-libre-arm64-mnt-reform kernel; changes in 6.12.31+ broke the patches, and applying those patches would not really be reasonable for all kernels (and should be getting smaller with newer kernels)... so having a board-specific kernels makes sense here. The biggest difference is the "full" kernel configurations tend to enable more things as modules, and the "generic" and board-specific configurations tend to enable more things as built-ins, which gets tricky because the initramfs handling of modules in guix is painfully primitive when using the "full" kernels on obscure machines (e.g. anything non-x86)... ...as upstream keeps changing the names of these modules and the names of these modules may differ on-disk vs. loaded (e.g. on-disk maybe uses foo-module and lsmod reports foo_module)... So a given initramfs module definition for a system configuration is basically tied to a specific kernel and version, rather than some resonable default modules we can use everywhere as with x86 in most cases. > I want users to take an active role in making decisions and > support. As it is now, it feels like I'm wasting my effort making > configs for hardware that I don't have and that nobody else seems to > use. Many thanks for that work! I do wonder at maintaining full kernel configurations as used for "linux-libre", with huge sets of configuration options defined that we probably could care less about, vs. the "generic" or board-specific configs which define the features we want and use the upstream defaults for the rest... I could see getting something similar to the full kernel configuration but defining the desired featureset using the method for the "generic" kernels... leveraging and improving how default-extra-linux-options is used and expanding into a full-extra-linux-options or some such, but maybe that is still a not particularly fun game of whack-a-mole either way! live well, vagrant
signature.asc
Description: PGP signature
