[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Replacing Yocto with Guix kernel image builds: best practices
From: |
Efraim Flashner |
Subject: |
Re: Replacing Yocto with Guix kernel image builds: best practices |
Date: |
Sun, 17 May 2020 16:20:43 +0300 |
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 <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature