Re: Replacing Yocto with Guix kernel image builds: best practices

[Efraim Flashner <efraim@flashner.co.il>]

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

On Sun, May 17, 2020 at 09:41:00PM +1000, Trevor Lee wrote:
> Hi,
> 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.
> 
> However, being new to Guix we are still coming grips with the best
> practice(s) for what we would like to do.
> We've looked at Guix's linux.scm, and
> Efraim Flashner's post[1] is our primary reference - many thanks Efraim.

I'd like to embarrassingly mention that I never actually booted any of
my custom kernels. My machine was a bit too slow to regularly compile
for some guess-and-check.

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

Something which I very recently learned is a command 'make savedefconfig'
which minimizes the .config to just a minimal number of Y/N/m answers
which, when used to compile a kernel, gives the same outcome as the full
config that spawned it. I've thought again about making a minimal kernel
for my machine and I haven't decided still if I'd go with savedefconfig
and translate it to a generated file or not.

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

I would probably start with one package each and then see how they could
be made to inherit from one another or grouped together. The way the
current make-linux-libre procedures work has grown quite a bit but they
should still mostly work as a starting point to add/remove bits for
customizing for your needs.

I don't think I'd go with different branches. If you keep everything in
one branch then it's easier to deduplicate work between the different
variants.

> Appreciate any comments suggestions or tips.
> 
> [1]:
> https://guix.gnu.org/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/
> [2]: https://guix.gnu.org/manual/en/guix.html#Channels
> 
> -- 
> Kind Regards
> 
> Begley Brothers Inc.
> 
> 
>    1. *The content of this email is confidential and intended for the
>    recipient specified in message only. It is strictly forbidden to share any
>    part of this message with any third party, without a written consent of the
>    sender. If you received this message by mistake, please reply to this
>    message and follow with its deletion, so that we can ensure such a mistake
>    does not occur in the future.*
>    2. *This message has been sent as a part of discussion between Begley
>    Brothers Inc. and the addressee whose name is specified above. Should you
>    receive this message by mistake, we would be most grateful if you informed
>    us that the message has been sent to you. In this case, we also ask that
>    you delete this message from your mailbox, and do not forward it or any
>    part of it to anyone else. Thank you for your cooperation and
>    understanding.*
>    3. *Begley Brothers Inc. puts the security of the client at a high
>    priority. Therefore, we have put efforts into ensuring that the message is
>    error and virus-free. Unfortunately, full security of the email cannot be
>    ensured as, despite our efforts, the data included in emails could be
>    infected, intercepted, or corrupted. Therefore, the recipient should check
>    the email for threats with proper software, as the sender does not accept
>    liability for any damage inflicted by viewing the content of this email.*
>    4. *The views and opinions included in this email belong to their author
>    and do not necessarily mirror the views and opinions of the company. Our
>    employees are obliged not to make any defamatory clauses, infringe, or
>    authorize infringement of any legal right. Therefore, the company will not
>    take any liability for such statements included in emails. In case of any
>    damages or other liabilities arising, employees are fully responsible for
>    the content of their emails.*

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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