Improving build-time checks for kernel module configuration + two other discussion points

[Richard Sent <richard@freakingpenguin.com>]

Hi Guix!

Guix provides both linux-libre and linux-libre-<system>-generic kernels.
The generic kernels seem to match the upstream defconfigs very closely
with a few minor adjustments (namely default-extra-linux-options) while
the linux-libre kernel is entirely customized.

This can result in awkward bugs when using Guix services that expect
certain options to be set. Generally, the linux-libre kernel seems to
have plenty of options set for Guix-packaged services to operate while
-generic kernels do not. These bugs are difficult for users to
troubleshoot without a lucky dive on the mailing list [1].

Unfortunately, -generic kernels can have better support for running Guix
on certain single board computers [1][2] or specific devices (e.g.
Pinebook Pro). This places users in an lose-lose situation of either a)
manually customizing the linux-libre kernel with the appropriate
upstream options until the system boots or b) adding config options
piecemeal to the -generic kernel as runtime breakages are detected.

My idea for how to mitigate this is adding some sort of extensible
service where services can register necessary kernel configuration
settings. When the config option is unset, a build-time error is raised.

Alternatively instead of merely verifying the config option, this
service could set the config option outright. However, without enhancing
customize-linux to recursively enable config dependencies [3] this may
not be feasible.

Does this sound reasonable? Looking at the code it seems the appropriate
places for verification would be in (guix scripts system) and (gnu
machine ssh) . Does anyone have a different suggestion? Did I miss the
mark?

Having skimmed the code this may be challenging to implement as it would
have to occur after the kernel is built. (Or at least after
guix_defconfig is generated.) At present all checks seem to be performed
/before/ building the OS. There's also system containers to consider.

A couple of other thoughts while I'm at it:

There doesn't seem to be much shared understanding on the meaning of
-generic kernels [4]. Perhaps we should consider renaming them while
we're at it or at least better document the distinction.

Several options are set in -generic kernels to provide support for
specific boards. (This is most notable in linux-libre-arm64-generic).
This doesn't feel like the cleanest solution to me. I think we should
instead make those kernels smaller, customized variants of (ideally)
linux-libre or linux-libre-*-generic so their purpose is a bit more
distinct.

To summarize here's the action items:

1. Add build-time checks for kernel config options
2. Better identify and/or document the meaning of -generic kernels.
3. If needed, adjust the behavior of -generic kernels to match 2 and add
variants as necessary.

Thoughts? 🧠💡

[1]: https://issues.guix.gnu.org/61173
[2]: https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/rsent/machines/lan/caustic.scm
[3]: https://issues.guix.gnu.org/66355#1-lineno28
[4]: https://issues.guix.gnu.org/43078#2

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.