From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id CCVvDicPaWYxkgAAqHPOHw:P1 (envelope-from ) for ; Wed, 12 Jun 2024 02:59:51 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id CCVvDicPaWYxkgAAqHPOHw (envelope-from ) for ; Wed, 12 Jun 2024 04:59:51 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=g9mKbMMF; dmarc=none; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718161191; a=rsa-sha256; cv=none; b=p+bQxGbsoWRU1G/NTD2HWTYyT9vVayd+tQbXCFG7/YGV8STVwAd24G7MfKQ0MLN6aAliQS Na49nFln/k+61X/OskFnAk20LB9Z/5Wlot87dm+Z1ukzRhNZOLcWyuJnUHvT0aQ90FHQu8 yGukv9I3mf6cDdiekaNSqYV1w+e0SL4JLO5COxbOHfbjY+L43acfSz6EduccYFTw/CSVSq ZbCNXF4BaLfzWzrdBlhiJqViDQPF1nDUKTAmMOpqsch4mBEcZSAFiwIoKma6tGdsvDsVGX tsmtMaeKP21whG4uDX/sYOplQe7VfGQWkei2qGmaznAh4OUkspkKW5DBC7kXSQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=freakingpenguin.com header.s=x header.b=g9mKbMMF; dmarc=none; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1718161191; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Db9k3hvfBcbdeIgmfGtmMVF07SzAbz+6wpbXzPINYs8=; b=Ru6BxRDT88K6NjPuLPPBH2Nf5taHqkO/MGkL9Hs9U0Th7CM7gPOkC5FSuiulsj/pzenTU0 33+3Tnoajuhx08nKCERwUyZhY/mG77FObkvyTkN2YQYohR3mwwaY7zbl2desr4cncTwy/s Zcszfy79UO/wB72TRfQHIJgVzMBJBlcRbKEJfu26GjgxWY5xsy80GWQnf10eMu/gBQKZZl HTfk748mQb4B1BSjjVzTlgUCdmFO7FHYI8FF461Vj0KPEucAune/Ay83Ia3R5m68RPVLBM N2w3pbsWJ0q2bE7wuB7r2ZIzO2FJLjWdQgbUxhEks2sPxNrBBCum6c1Z0tCUKA== 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 23FFE1FEA5 for ; Wed, 12 Jun 2024 04:59:51 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHECW-00079P-Fx; Tue, 11 Jun 2024 22:59:04 -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 1sHECU-00078z-RV for guix-devel@gnu.org; Tue, 11 Jun 2024 22:59:02 -0400 Received: from mail-108-mta253.mxroute.com ([136.175.108.253]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sHECS-0001DR-BZ for guix-devel@gnu.org; Tue, 11 Jun 2024 22:59:02 -0400 Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta253.mxroute.com (ZoneMTA) with ESMTPSA id 1900a62564c00017a3.001 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 12 Jun 2024 02:58:55 +0000 X-Zone-Loop: e81debeaca34fb49531906c1d78031f84bc720f7494d X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=freakingpenguin.com; s=x; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Db9k3hvfBcbdeIgmfGtmMVF07SzAbz+6wpbXzPINYs8=; b=g9mKbMMFb5RduZ7mZofbZaZ25x iTS2NcV+dJ4TUfouBqrE7Q1cCHeRuyn0c1ObLrCxpH/P9BjYPE23gm8lTBE2UCoqeM3oi9o8gRRpB 3fuccj9Fa9UX6GjuFo8PUXntBBkqOgpeZeZM1O6x4oHnK1TgVvpM1rmssT4Iu2d9HJ4AB1OKWdJcp dZ/TKjZVHMtxrMPgcQU/P2/uNY0CaYc6Z5liH7t7b7yDhD7Yjhv4u/KVsXPGNa02U/acuozcrIIz/ yPeKS1etB49riBhJbHVkSqSkvyYH4TLjW0uXq7aIAXxU8F0WXnEdLy7cBXU0ufsN55wdepqTvtB4m LUQuS+2Q==; From: Richard Sent To: guix-devel@gnu.org Subject: Improving build-time checks for kernel module configuration + two other discussion points Date: Tue, 11 Jun 2024 22:58:47 -0400 Message-ID: <87tthy50k8.fsf@freakingpenguin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Authenticated-Id: richard@freakingpenguin.com Received-SPF: pass client-ip=136.175.108.253; envelope-from=richard@freakingpenguin.com; helo=mail-108-mta253.mxroute.com X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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-Migadu-Queue-Id: 23FFE1FEA5 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -6.34 X-Spam-Score: -6.34 X-TUID: rYE7HkS+tz1h Hi Guix! 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]. Unfortunately, -generic kernels can have better support for running Guix on certain single board computers [1][2] or specific devices (e.g. Pinebook Pro). This places users in an lose-lose situation of either a) manually customizing the linux-libre kernel with the appropriate upstream options until the system boots or b) adding config options piecemeal to the -generic kernel as runtime breakages are detected. 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. 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. 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? 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. 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. To summarize here's the action items: 1. Add build-time checks for kernel config options 2. Better identify and/or document the meaning of -generic kernels. 3. If needed, adjust the behavior of -generic kernels to match 2 and add variants as necessary. Thoughts? =F0=9F=A7=A0=F0=9F=92=A1 [1]: https://issues.guix.gnu.org/61173 [2]: https://git.sr.ht/~freakingpenguin/rsent/tree/master/item/rsent/machin= es/lan/caustic.scm [3]: https://issues.guix.gnu.org/66355#1-lineno28 [4]: https://issues.guix.gnu.org/43078#2 --=20 Take it easy, Richard Sent Making my computer weirder one commit at a time.