From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 6AjuL2I0wV56MwAA0tVLHw (envelope-from ) for ; Sun, 17 May 2020 12:56:02 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kOPdK2I0wV6CWAAAB5/wlQ (envelope-from ) for ; Sun, 17 May 2020 12:56:02 +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 8FEC6940510 for ; Sun, 17 May 2020 12:56:01 +0000 (UTC) Received: from localhost ([::1]:50160 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaIpk-0004Nw-J5 for larch@yhetil.org; Sun, 17 May 2020 08:56:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaIpb-0004Nq-Lg for guix-devel@gnu.org; Sun, 17 May 2020 08:55:51 -0400 Received: from sender4-of-o53.zoho.com ([136.143.188.53]:21311) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1jaIpZ-00032K-CA for guix-devel@gnu.org; Sun, 17 May 2020 08:55:50 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1589720144; cv=none; d=zohomail.com; s=zohoarc; b=ilxEdHyHnbeuId8d9zl6eGHq1sVp6OyTTk99kPwnoOY3pdV2akVGihBW9yjA2xy7GYzBtBfFyxml1stkGc1vQjdAdcPPFSRRu6R22ar11vZk0IEG9HQdGvUfHlz+fLLsKFsC0vLfP6yF2AuR9dXmAE2eO0mvPA5d2sEeD2PoY2U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1589720144; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=Y+gaDrEHhXnvarCsfwhaLkc/IsfH36ObelcM4V/mfOw=; b=eTefmcnHP4Kc0mLmSjMARIN+edORT/obVwinNeYDZSf3V9vQc5Jqf9LPMRdLEQ1VAe3/Lk920XJ15PV37f5FJyt9ehIFggTEbagLhvjAVhdyjXNb78pPXmbxY9Nr4U8ye1QxW1J+sdNS/JvDlKeLdzVuA9062DqRgM0IWDRVx5k= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1589720144; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=Y+gaDrEHhXnvarCsfwhaLkc/IsfH36ObelcM4V/mfOw=; b=WvxA4N5/T+E2PrZ1mSTjlc8V7WVhsts385CVWZM8U8FetVItST+kxFkV78JsQxPf mWVitjBfmTRO4p/pUB/TjdZ+qaq7aF3yeReKltRoixubrKiyziuFwPkNo4UOOTdaByC gpVJ29dYFwqnLE43dFo10XoCFrIBSvB8D5fDBD80= Received: from localhost (p4fd5ab9e.dip0.t-ipconnect.de [79.213.171.158]) by mx.zohomail.com with SMTPS id 1589720141414312.8568467818284; Sun, 17 May 2020 05:55:41 -0700 (PDT) References: User-agent: mu4e 1.4.4; emacs 26.3 From: Ricardo Wurmus To: guix-devel@gnu.org Subject: Re: [GNU-linux-libre] Replacing Yocto with Guix kernel image builds: best practices In-reply-to: X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Sun, 17 May 2020 14:55:38 +0200 Message-ID: <87lflqhgad.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.53; envelope-from=rekado@elephly.net; helo=sender4-of-o53.zoho.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/17 08:08:45 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=elephly.net header.s=zoho header.b=WvxA4N5/; 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: 1.99 X-TUID: OZa/6Tm9veCZ 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. [=E2=80=A6] > We'd appreciate any pointers to package definition(s) that demonstrate be= st > practices to do what we'd like: > > - 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. > > 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 t= hat to the native inputs, or you can include the config files in your channel repository (or later in Guix itself). > 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.... > > 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. 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. > 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? If the main differences between kernel variants are not in the package definition but the sources and the configuration file I=E2=80=99d suggest defining a procedure that returns a package value. You can then define multiple packages in terms of that procedure. --=20 Ricardo