From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cNvMHhwwwV5kcwAA0tVLHw (envelope-from ) for ; Sun, 17 May 2020 12:37:48 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id CEfIGhwwwV6IRAAA1q6Kng (envelope-from ) for ; Sun, 17 May 2020 12:37:48 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C8760940B0D for ; Sun, 17 May 2020 12:37:47 +0000 (UTC) Received: from localhost ([::1]:33372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaIY6-0004ML-K1 for larch@yhetil.org; Sun, 17 May 2020 08:37:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49252) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaHfq-0008Ma-ST for guix-devel@gnu.org; Sun, 17 May 2020 07:41:42 -0400 Received: from mail-lf1-x143.google.com ([2a00:1450:4864:20::143]:45796) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaHfn-0001zo-Sh for guix-devel@gnu.org; Sun, 17 May 2020 07:41:42 -0400 Received: by mail-lf1-x143.google.com with SMTP id a4so5507669lfh.12 for ; Sun, 17 May 2020 04:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZY+U58XI+AQ0iz4/NnPqEDRxGFOegBD4qRXLrKyXFHc=; b=YDl8qWgRPlQWMl6krh+A3Gnuw1/vqRQoEINMqatDdr3PoNQV4zMpld8VXY2GdDffxM /y1ORaNBXJUDKKpd9xhkQZZPTeeQyqAufIlNn/RvnVXUIHvisNRb8BSdiwyZnccEqa2X j9OlP2Seyg5BFbHO5/FVjOmh4C3cMRbD+isljdL/MczIwwSeTbAZbPlAp5/gjls/cGJX xs383s1DTvKy1R1tfwmZUP3qvZfXP7Qj1gWFPinzs84r2k/a0136rHTAyPOz98X/TJ4m XH+r+XefHUKYBFw0TLJ3URroETTsdYlWFvWBaLhnoUkUhUBuv3H9W+xY13P+3Gm5WgyC b0Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZY+U58XI+AQ0iz4/NnPqEDRxGFOegBD4qRXLrKyXFHc=; b=mmuAVVBCOwlR+RA9OT4f9s84jwfMth12A/LhlH77rschHkRq4XLjrXciADuBqs1dq/ W7I10H65QBweJwMHEs+HKRYO3DXeZ/Tb9JHqjoBXy8j3F7nW1VI812Tk9pmPdeIZqyE4 323ZbxUKr9G4hcrI0Yt+Dq3Hm+rhUzHB94smH3wJrDt9VdoCrSVxo/jH7Dg4iU556if5 8un3aHBD2SnzPm2Icc+tNWpBRBLkwuFh+MHZCBwfcU83U7G/CLMGr0BZB7R2pkC3Od+C Moqm93VIXGrT+dimGfzQUD7z9I/jEL1RJTBaWpmgN4ins2XIHukaC069dltniulynUj0 j0LA== X-Gm-Message-State: AOAM530XssfrwiuQKeabMm3WDM04jq6DaNlD+9yf7NjdNlcpDDbcFsSX 8A5LbrgFw5f26vwc6kQHIEE/5E0R1c0ADzANSmjdYI6F X-Google-Smtp-Source: ABdhPJyTkdr7JzBJMY/vFI5R0xVUIWkywhpkFuovsKk558vuPTCsgSPBLWYI7eQKmXnOsA3t/DKZV4iBCV7eoK0BsJk= X-Received: by 2002:a05:6512:10c8:: with SMTP id k8mr7532635lfg.181.1589715697261; Sun, 17 May 2020 04:41:37 -0700 (PDT) MIME-Version: 1.0 From: Trevor Lee Date: Sun, 17 May 2020 21:41:00 +1000 Message-ID: Subject: Replacing Yocto with Guix kernel image builds: best practices To: guix-devel@gnu.org Content-Type: multipart/alternative; boundary="0000000000006de1b205a5d687d5" Received-SPF: pass client-ip=2a00:1450:4864:20::143; envelope-from=begleybrothers@gmail.com; helo=mail-lf1-x143.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Mailman-Approved-At: Sun, 17 May 2020 08:37:37 -0400 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=YDl8qWgR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: 11URFqrLJJZ8 --0000000000006de1b205a5d687d5 Content-Type: text/plain; charset="UTF-8" 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. 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.... 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? 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.* --0000000000006de1b205a5d687d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
We are now looking to build Linux kerne= ls using Guix=20 instead of Yocto.=C2=A0 We can't see any reason why the builds wouldn&#= 39;t be=20 linux-libre. Ideally we'd like our effort to be accepted by upstream=20 guix.

However, being new to Guix we are still comi= ng 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.
<= div>
We'd appreciate any pointers to package definition(s= ) that demonstrate best practices to do what we'd like:

<= /div>
- 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'=20 configuration is applied to for each of a machine 'type' (3 machine= =20 types) and one of two 'arch'.
- Currently we can generate= a=20 full kernel `.config` for a kernel+base+variant+arch (we are working on=20 the best way to handle different machines if we are not using Yocto.)
- We'd ideally like to generate `vmlinux`, `initrd` and `rootf= s` images=C2=A0for 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".=C2=A0 Assume we resolve the machine definition issue.= =C2=A0=20 However we're puzzled about how to best distribute the configuration=20 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=20 config file is what is puzzling. Some options we thought about seem=20 inelegant - hence too embarassing to mention - so we'll skip them ;)=20 Leaving....

1) We did wonder if channels[2]=20 were the way to go with each kernel x.y.z in its own branch and config=20 files therein. Could anyone point us to packages that setup and use=20 package specific channels?
2) Should we be aiming to provide a single package with multiple parameters or is it better to provide a=20 package for each kernel x.y.z, or some other partitioning. We'd likely= =20 want to script the package definition then - correct?

Appreciate any comments suggestions or tips.
=C2=A0
[1]: https://guix.gnu.org/= blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/=
--
Kind Regards

Begley= Brothers Inc.

  1. The content of this email is con= fidential and intended for the=20 recipient specified in message only. It is strictly forbidden to share=20 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 addresse= e whose name is specified above. Should=20 you receive this message by mistake, we would be most grateful if you=20 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=20 it or any part of it to anyone else. Thank you for your cooperation and=20 understanding.
  3. Begley Brothers Inc. puts= the security of the client at a high priority.=20 Therefore, we have put efforts into ensuring that the message is error=20 and virus-free. Unfortunately, full security of the email cannot be=20 ensured as, despite our efforts, the data included in emails could be=20 infected, intercepted, or corrupted. Therefore, the recipient should=20 check the email for threats with proper software, as the sender does not accept liability for any damage inflicted by viewing the content of=20 this email.
  4. The views and opinions included in this email be= long to their author and do not necessarily mirror the views and opinions of the company.=20 Our employees are obliged not to make any defamatory clauses, infringe,=20 or authorize infringement of any legal right. Therefore, the company=20 will not take any liability for such statements included in emails. In=20 case of any damages or other liabilities arising, employees are fully=20 responsible for the content of their emails.
--0000000000006de1b205a5d687d5--