From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id EKgjAQJZaWa+AgEAe85BDQ:P1 (envelope-from ) for ; Wed, 12 Jun 2024 08:14:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id EKgjAQJZaWa+AgEAe85BDQ (envelope-from ) for ; Wed, 12 Jun 2024 10:14:58 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=coEohwAW; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1718180097; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=W821fhOQYVcuJbDkXwCMPPdjqcdkj/OYWtXr025vQxA=; b=WP35g4gG2xj6mlkZSG6vp78NrdA+Zq8hlMLaI3mr6gA2vyc3I9pUydb59mhf2FwDYKXhnm G4PNf+jDgQynj2HaM7QtTT21mg9+pswbHWjZx81RbBQUn4OwYc9MMsNwi6EJgwrvCpUY9M 620wf1mqETluJtnYVgLy3hWvwsqKQ3+XbzfOmKx6KTuHCYLpqKMkXF0NyBQa5GTpvXkZRB eLLXpsPrFel+9lnr9qHVGM/eJsiS5WF+mZWuc0qhTiyGibC6/UXdlQjsyuniTiuQCGi0aS YScwuwPS/+lx70xEOhliaDVrIE/10CeQIFU+cjEb4PbI+DMYQhdnoiKGWCT5TA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=debian.org header.s=1.vagrant.user header.b=coEohwAW; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718180097; a=rsa-sha256; cv=none; b=RzuTlkt22ElU3qR2sJMia0yxYrVwJhMrlgyqFjnyLMvdu+u6OR/GaA9bQGtu9Q/4kFkXfL eFQnMk0yKSj7SoU4RxVl40NeMyFMskIweikNtl7UYztNxZMO2EAzXsPCIljGJ10KzvP6nA RvEIYaoi0LimhnTfkH58aQ7AV1+bhCH8TxUXh8+dcJeNI1LbF3e80Oqd8gN2GdJxZ7VAZg QJZnxkG4EUBwXfJvKfwqPZxbO7x9dVAa2TxxDVXARZUZwDlAxX25xEZtNM8r6/5YzPpEjk Mb2Q3XaziORWwH6e5ijnG0UFsZNsWUQxr2cmnrG2eBZ/E25eQtUI7b5/uwQgOg== 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 CB2CA6EADD for ; Wed, 12 Jun 2024 10:14:57 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHJ7X-0001xv-F9; Wed, 12 Jun 2024 04:14:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHJ7V-0001xb-Ma for guix-devel@gnu.org; Wed, 12 Jun 2024 04:14:14 -0400 Received: from cascadia.aikidev.net ([2600:3c01:e000:267:0:a171:de7:c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHJ7T-0006Dy-Bv for guix-devel@gnu.org; Wed, 12 Jun 2024 04:14:13 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:50]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id C3C3E1AFA5; Wed, 12 Jun 2024 01:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1718180040; bh=4yy+rz70f27UtsUAzCA1xX1Sn074Ova43MjarFtw178=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=coEohwAWkQJ6erFgwEsAqKbU+9aGzNEffRkxGbKUdgyptOB9fq90bexvS0YBpi1W3 8VQ3tUNBtB8lOl5FGKMIUEdC3xgP+CSXzxgvNnNrtHGOcPi4I97zc541rG1fHOCxsm ZiC46R/NmRItiVI25kwq+J9TuY95KTN0d0Fj9b52U3nVmDMzOGwMT8bPf3cn6RNecF 92nk3nc86oH9cXSjiwlB1A9Cn/6ihJE7oONYd4AfQg7bgyjlV9NstjqtTIBooDac4w O04hbRfClLIqIbMXdwttJ+k8r4nBGUEtxKyUsESqoP7oP6Yigpa93MTCPFk2PjGsmq nN3LKUskmfjKQ== From: Vagrant Cascadian To: Richard Sent Cc: guix-devel@gnu.org Subject: Re: Improving build-time checks for kernel module configuration + two other discussion points In-Reply-To: <87tthy50k8.fsf@freakingpenguin.com> References: <87tthy50k8.fsf@freakingpenguin.com> Date: Wed, 12 Jun 2024 01:13:54 -0700 Message-ID: <87wmmumvct.fsf@wireframe> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: none client-ip=2600:3c01:e000:267:0:a171:de7:c; envelope-from=vagrant@debian.org; helo=cascadia.aikidev.net X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.141, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -13.03 X-Migadu-Queue-Id: CB2CA6EADD X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -13.03 X-TUID: ptXY2As1fz+H --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2024-06-11, Richard Sent wrote: > Guix provides both linux-libre and linux-libre--generic kernels. > The generic kernels seem to match the upstream defconfigs very closely > with a few minor adjustments (namely default-extra-linux-options) while > the linux-libre kernel is entirely customized. > > This can result in awkward bugs when using Guix services that expect > certain options to be set. Generally, the linux-libre kernel seems to > have plenty of options set for Guix-packaged services to operate while > -generic kernels do not. These bugs are difficult for users to > troubleshoot without a lucky dive on the mailing list [1]. The whole point of default-extra-linux-options (in my mind) is to include all those things that should be enabled by default in any guix kernel, so if there are missing features, I would say they should be added to default-extra-linux-options... then we can easily document why features X, Y and Z are enabled or disabled... and can error out the build if a desired feature is inappropriately included or inappropriately not included. I sometimes wonder why kernel configs are hand-crafted at all, instead of just declaring all the features we want from all the linux-libre kernels... Maybe "all the features" is too hard to define... but like all things, can be incrementally improved... As mentioned, maybe kernel build dependencies make it a bit complicated! Maybe the answer is "someone has not coded it yet" and that is valid enough... As someone entirely without the skill to actually code it, it would seem the more "guix" way to define a kernel configuration declaratively as what is wanted or not wanted, rather than passing a manually massaged kernel configuration file... :) > My idea for how to mitigate this is adding some sort of extensible > service where services can register necessary kernel configuration > settings. When the config option is unset, a build-time error is raised. That sounds good to me, although I am not sure why it should be a runtime service; it seems like a part of the kernel package build process, but maybe this is just a difference in choice of words? Or I could be missing something entirely! > Alternatively instead of merely verifying the config option, this > service could set the config option outright. However, without enhancing > customize-linux to recursively enable config dependencies [3] this may > not be feasible. I hear people praise the recursion of scheme and lisp and whatnot, so, time to let it shine, perhaps? :) > Does this sound reasonable? Looking at the code it seems the appropriate > places for verification would be in (guix scripts system) and (gnu > machine ssh) . Does anyone have a different suggestion? Did I miss the > mark? Are you just saying you want a service ensures the system has the specific feature set required? I am not sure where the best place to do that, mostly I think of it as a property of the kernel build itself... but I guess a system configuration spot-check could be interesting... > Having skimmed the code this may be challenging to implement as it would > have to occur after the kernel is built. (Or at least after > guix_defconfig is generated.) At present all checks seem to be performed > /before/ building the OS. There's also system containers to consider. I thought containers do not have a kernel (other than the host machine kernel) ... but I could easily be missing something! > A couple of other thoughts while I'm at it: > > There doesn't seem to be much shared understanding on the meaning of > -generic kernels [4]. Perhaps we should consider renaming them while > we're at it or at least better document the distinction. ... > Several options are set in -generic kernels to provide support for > specific boards. (This is most notable in linux-libre-arm64-generic). > This doesn't feel like the cleanest solution to me. I think we should > instead make those kernels smaller, customized variants of (ideally) > linux-libre or linux-libre-*-generic so their purpose is a bit more > distinct. My thought having previously (though not recently!) proposed and (briefly/poorly) maintained a few of the -generic kernels was to ideally just use the upstream defconfig as much as possible (which tends to track board or board-family changes across versions a bit better that we could reasonably expect of guix maintainers), only adding guix-specific features, or the occasional board-specific feature (and board-specific features should eventually also get submitted for inclusion upstream). Typically, my goal was to use the -generic variant just to get something booting quickly, that would have a decent chance of working on arbitrary new boards as they are added upstream, and then work on adding the features necessary (and list of modules to add to the initrd) to get it working with the appropriate default "linux-libre" kernel. I do wonder if anyone is actually using any of the (32-bit) linux-libre-arm-* variants ... > To summarize here's the action items: > > 1. Add build-time checks for kernel config options Sure! > 2. Better identify and/or document the meaning of -generic kernels. Sounds good! > 3. If needed, adjust the behavior of -generic kernels to match 2 and add > variants as necessary. Sounds like a good summary to me. :) > Thoughts? =F0=9F=A7=A0=F0=9F=92=A1 Thanks for raising these questions! It has been a while since I've booted any off-beat architecture guix machines, and thus poked at any of these issues... but it is interesting to at least evaluate and think about better ways of approaching or even understanding the various challenges! live well, vagrant > [1]: https://issues.guix.gnu.org/61173 > [2]: https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/rsent/mach= ines/lan/caustic.scm > [3]: https://issues.guix.gnu.org/66355#1-lineno28 > [4]: https://issues.guix.gnu.org/43078#2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZmlYwgAKCRDcUY/If5cW qlwMAP9sQC7XwkZsT2w6KR3xzDe9SEAwficN+/eJ+VdICzWQVQEA44uzoK44toOF iUCA/a1TGvV3KpvazfQ6Msyxa5w8fQg= =N+bf -----END PGP SIGNATURE----- --=-=-=--