On 2024-06-11, Richard Sent wrote: > Guix provides both linux-libre and linux-libre--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