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

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

[Richard Sent]

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.

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

[Vagrant Cascadian]

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

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

[Attila Lendvai]

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


the meaning of 'service' in the guix context is quite different than what that word means to most people today.

you should think of it as a component of the declarative OS definition (as opposed to as a runtime agent that responds to requests).

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“You cannot legislate the poor into freedom by legislating the wealthy out of freedom. And what one person receives without working for, another person must work for without receiving. The government can’t give to anybody anything that the government does not first take from somebody. And when half of the people get the idea they don’t have to work because the other half’s going to take care of them, and when the other half get the idea it does no good to work because somebody’s going to get what I work for. That, dear friend, is about the end of any nation. You cannot multiply wealth by dividing it.”
	— Adrian Rogers (1931–2005), 1984

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

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Vagrant,

On Wed, Jun 12 2024, Vagrant Cascadian wrote:

> maybe this is just a difference in choice of words?

Because your video [1] brought me to Guix long after you discovered your
own "crush" on it, I feel silly writing here, but like Attila said:

   Guix services are features.

Kind regards
Felix

[1] https://debconf18.debconf.org/talks/99-my-crush-on-gnu-guix/