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 GHH5MVw6wV4zbwAA0tVLHw (envelope-from ) for ; Sun, 17 May 2020 13:21:32 +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 yBzALVw6wV7dZAAA1q6Kng (envelope-from ) for ; Sun, 17 May 2020 13:21:32 +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 4C63E940143 for ; Sun, 17 May 2020 13:21:32 +0000 (UTC) Received: from localhost ([::1]:45246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaJER-0008C8-9O for larch@yhetil.org; Sun, 17 May 2020 09:21:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaJEF-0008As-Cn for guix-devel@gnu.org; Sun, 17 May 2020 09:21:19 -0400 Received: from flashner.co.il ([178.62.234.194]:60050) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaJED-00010Q-NN for guix-devel@gnu.org; Sun, 17 May 2020 09:21:19 -0400 Received: from localhost (unknown [188.120.128.132]) by flashner.co.il (Postfix) with ESMTPSA id 56D6D401C7; Sun, 17 May 2020 13:21:16 +0000 (UTC) Date: Sun, 17 May 2020 16:20:43 +0300 From: Efraim Flashner To: Trevor Lee Subject: Re: Replacing Yocto with Guix kernel image builds: best practices Message-ID: <20200517132043.GE31833@E5400> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u5E4XgoOPWr4PD9E" Content-Disposition: inline In-Reply-To: X-PGP-Key-ID: 0x41AAE7DCCA3D8351 X-PGP-Key: https://flashner.co.il/~efraim/efraim_flashner.asc X-PGP-Fingerprint: A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Received-SPF: pass client-ip=178.62.234.194; envelope-from=efraim@flashner.co.il; helo=flashner.co.il X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/17 08:06:21 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; 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: 0.69 X-TUID: OZaSX0XPUchA --u5E4XgoOPWr4PD9E Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 be= st > practices to do what we'd like: >=20 > - We'd like to build custom configured kernels for each patch series in t= he > 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 f= or > each. >=20 > 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 th= an > 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 paramete= rs > 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. >=20 > [1]: > https://guix.gnu.org/blog/2019/creating-and-using-a-custom-linux-kernel-o= n-guix-system/ > [2]: https://guix.gnu.org/manual/en/guix.html#Channels >=20 > --=20 > Kind Regards >=20 > Begley Brothers Inc. >=20 >=20 > 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 o= f 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 mis= take > 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 info= rmed > us that the message has been sent to you. In this case, we also ask th= at > 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 messag= e 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 c= heck > the email for threats with proper software, as the sender does not acc= ept > liability for any damage inflicted by viewing the content of this emai= l.* > 4. *The views and opinions included in this email belong to their auth= or > and do not necessarily mirror the views and opinions of the company. O= ur > 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.* --=20 Efraim Flashner =D7=90=D7=A4=D7=A8=D7=99=D7=9D = =D7=A4=D7=9C=D7=A9=D7=A0=D7=A8 GPG key =3D A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted --u5E4XgoOPWr4PD9E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAl7BOigACgkQQarn3Mo9 g1HcuBAAjLVDfx23WdwnyJTUdkY9ZrdfKT8bGfNCiHiSW56I53qWk6ECKr84myoc U3arE/6BRjUQ4rllDSF34rLuHg8n4m34OZ5PFYmfT12YZ65N1cBUZftNljt36148 MX6GvRK9qtEmv9Uekrwb9xCzhIw0f4xIqykzUxBfR5NLVH1UP+jy7FqIZe/ULHnp UgsyY+lZiKeMMAlCH0kKOt9/N4VTjJ7zZqkeWHLO6GDBWnhRd9V+gsMfoGZJNYGN R5K25XC5mo5bjH9CHA25pW5mhe35jhzTw7Nvr9y1RxANWlvv5Q2o2KuIN0f48Rl+ A2P7hP6pz1jMF1kufPqzOzLNLwGFpKOD9eTbtoA5XU1TbzXVb8ySrAMKAoeaaOrl wN78EvO0RhGV4rf9oZVu1J06h1J01QpmGa1G5cH6oiOxrLsdDSUyDL4QSCmatRQL /eyn3rBoIjX8al2U8BXSSa+IV/oOSHXof0OLlMQcHd4TKqMWyuacvWh514rxfvVv 9BYF+xaGourh8XhePUoucT2bN3r5tIvK4iEcpRT61cAUxSn+EqIKiOMoWRcDwSyQ tAQtTUdFeSpHANDVUBFUgSzKkIYZ8zdF57eyF6m7qDOUYTuDa1fE//0ksI+sJ6YS zP5EobmpbYfAnah7IFE5lTtHReqhBMQCKFCvmQz2yDKEyXMo4tU= =TT44 -----END PGP SIGNATURE----- --u5E4XgoOPWr4PD9E--