|
From: | Begley Brothers Inc |
Subject: | Re: Replacing Yocto with Guix kernel image builds: best practices |
Date: | Mon, 18 May 2020 07:23:12 +1000 |
On Sun, May 17, 2020 at 09:41:00PM +1000, Begley Brothers Inc 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.
> 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
[Prev in Thread] | Current Thread | [Next in Thread] |