Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices

[Ricardo Wurmus <rekado@elephly.net>]

Hi,

[+guix-devel, -gnu-linux-libre]

> We are now looking to build Linux kernels using Guix instead of Yocto.  We
> can't see any reason why the builds wouldn't be linux-libre. Ideally we'd
> like our effort to be accepted by upstream guix.
[…]
> We'd appreciate any pointers to package definition(s) that demonstrate best
> practices to do what we'd like:
>
> - We'd like to build custom configured kernels for each patch series in the
> LTS 4.14.72+, 4.19+ and 5.4+.
> - Currently we have two `base` kernel configs that each 'variant'
> configuration is applied to for each of a machine 'type' (3 machine types)
> and one of two 'arch'.
> - Currently we can generate a full kernel `.config` for a
> kernel+base+variant+arch (we are working on the best way to handle
> different machines if we are not using Yocto.)
> - We'd ideally like to generate `vmlinux`, `initrd` and `rootfs` images for
> each.
>
> Based on Efraim's post we think the first example is the least friction -
> "including an actual .config file as a native input to our custom kernel".
> Assume we resolve the machine definition issue.  However we're puzzled
> about how to best distribute the configuration file such that a build of
> kernel x.y.z can be updated with fixes.

You can either put your config files in a separate git repository and add that to
the native inputs, or you can include the config files in your channel
repository (or later in Guix itself).

> The constraint of users being able to use the std guix commands rather than
> telling them to download a config file or clone a git repo and copy a
> config file is what is puzzling. Some options we thought about seem
> inelegant - hence too embarassing to mention - so we'll skip them ;)
> Leaving....
>
> 1) We did wonder if channels[2] were the way to go with each kernel x.y.z
> in its own branch and config files therein. Could anyone point us to
> packages that setup and use package specific channels?

Channels handle all the gnarly bits of interacting with git.  Users who
would like to add your channel providing alternative kernels would only
need to add it to their ~/.config/guix/channels.scm file.

But since your stated goal is to add these definitions to Guix itself
you can simply add the kernel variants to linux.scm and include the
config files in the repository.

> 2) Should we be aiming to provide a single package with multiple parameters
> or is it better to provide a package for each kernel x.y.z, or some other
> partitioning. We'd likely want to script the package definition then -
> correct?

If the main differences between kernel variants are not in the package
definition but the sources and the configuration file I’d suggest
defining a procedure that returns a package value.  You can then define
multiple packages in terms of that procedure.

-- 
Ricardo