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

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

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

On Mon, May 18, 2020 at 07:40:53AM +1000, Begley Brothers Inc wrote:
> On Sun, May 17, 2020 at 10:55 PM Ricardo Wurmus <rekado@elephly.net> wrote:
> 
> >
> > 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).
> >
> 
> Thanks for the suggestion.  That gives some assurance.
> Could you point to an existing guix (upstream) package that is a best
> practice
> example of each of those two approaches?
> - accessing files from a separate repo
> - a guix (upstream) package using other files
> 

Do you mean something like this? It's a container instead of a full disk
image but it seems close enough. The 'gn' namespace is local to that
repo and 'gnu' and 'guix' are from the upstream guix repo.
http://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics/src/branch/master/gn/services/bnw-container.scm

> > 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.
> >
> 
> Can "add it to their ~/.config/guix/channels.scm file" be scripted as part
> of the
> package?
> Is there an example of a guix (upstream) package that does this?
> 
> 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.
> >
> 
> Current guix/linux.scm seems to take a different approach and cater to a
> different use cases - but our understanding of the code is limited and no
> doubt flawed.
> We think a three step process:
> 
> 1. Get a package definition working and publicly available.
> 2. Make any changes to get it accepted as a separate package by guix.
> 3. Consider whether merging with guix/linux.scm is what linux-libre folks
>     want
> 
> > 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.
> >
> 
> Thanks for that suggestion.  It seems the issue to resolve is the best
> approach for getting those config files to the users machine.
> 
> Thanks again
> 
> 
> > --
> > Ricardo
> >
> 
> 
> -- 
> 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 --]