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

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 6051 bytes --]

On 2024-06-11, Richard Sent wrote:
> 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].

The whole point of default-extra-linux-options (in my mind) is to
include all those things that should be enabled by default in any guix
kernel, so if there are missing features, I would say they should be
added to default-extra-linux-options... then we can easily document why
features X, Y and Z are enabled or disabled... and can error out the
build if a desired feature is inappropriately included or
inappropriately not included.

I sometimes wonder why kernel configs are hand-crafted at all, instead
of just declaring all the features we want from all the linux-libre
kernels...

Maybe "all the features" is too hard to define... but like all things,
can be incrementally improved...

As mentioned, maybe kernel build dependencies make it a bit complicated!

Maybe the answer is "someone has not coded it yet" and that is
valid enough...

As someone entirely without the skill to actually code it, it would seem
the more "guix" way to define a kernel configuration declaratively as
what is wanted or not wanted, rather than passing a manually massaged
kernel configuration file... :)


> 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.

That sounds good to me, although I am not sure why it should be a
runtime service; it seems like a part of the kernel package build
process, but maybe this is just a difference in choice of words? Or I
could be missing something entirely!


> 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.

I hear people praise the recursion of scheme and lisp and whatnot, so,
time to let it shine, perhaps? :)


> 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?

Are you just saying you want a service ensures the system has the
specific feature set required? I am not sure where the best place to do
that, mostly I think of it as a property of the kernel build
itself... but I guess a system configuration spot-check could be
interesting...


> 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.

I thought containers do not have a kernel (other than the host machine
kernel) ... but I could easily be missing something!


> 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.

My thought having previously (though not recently!) proposed and
(briefly/poorly) maintained a few of the -generic kernels was to ideally
just use the upstream defconfig as much as possible (which tends to
track board or board-family changes across versions a bit better that we
could reasonably expect of guix maintainers), only adding guix-specific
features, or the occasional board-specific feature (and board-specific
features should eventually also get submitted for inclusion upstream).

Typically, my goal was to use the -generic variant just to get something
booting quickly, that would have a decent chance of working on arbitrary
new boards as they are added upstream, and then work on adding the
features necessary (and list of modules to add to the initrd) to get it
working with the appropriate default "linux-libre" kernel.

I do wonder if anyone is actually using any of the (32-bit)
linux-libre-arm-* variants ...


> To summarize here's the action items:
>
> 1. Add build-time checks for kernel config options

Sure!

> 2. Better identify and/or document the meaning of -generic kernels.

Sounds good!

> 3. If needed, adjust the behavior of -generic kernels to match 2 and add
> variants as necessary.

Sounds like a good summary to me. :)


> Thoughts? 🧠💡

Thanks for raising these questions!

It has been a while since I've booted any off-beat architecture guix
machines, and thus poked at any of these issues... but it is interesting
to at least evaluate and think about better ways of approaching or even
understanding the various challenges!


live well,
  vagrant


> [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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]