From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4286D1582EF for ; Tue, 04 Mar 2025 15:49:21 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 233AD343196 for ; Tue, 04 Mar 2025 15:49:21 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id 5E0A31103D5; Tue, 04 Mar 2025 15:48:39 +0000 (UTC) Received: from mail-4317.protonmail.ch (mail-4317.protonmail.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 554291102D0 for ; Tue, 04 Mar 2025 15:48:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asokolov.org; s=protonmail3; t=1741103314; x=1741362514; bh=wGU3xkkOShdGkNImFNnOR7iYtOOOVmDV2p9SEz0HRZk=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Lza6buak3NHaaBlmucXPT5TxACQ3FRDqPHBcwKMGAdgZPmYO0wfcmxCw445Wf9FFx h/BPOfWZ3TkKN68askaNQYWn2NV7InKSrD1VHixhLVYQJB3O1lT+wq7kxcfu71jDIv EMdL5NkGEEdAzBACKAFzbfzcwFTqtj6nudnf8CvLI08hvX4yhth54ZrpZZR6t+lvax 0/mi7D9+ljwp78sxQ5nvuQR3jgm459wkVwUJDJpaLtZd71isZ1Hs13V4VHQoZvx81N z0KKKGkWqabt9P1iK9Pte+XGyqDEQpjwM9LSChdu/z+8/pSW+UxJORiUSbI3aAqQYj QTyunKQf+c2Rw== Date: Tue, 04 Mar 2025 15:48:31 +0000 To: gentoo-dev@lists.gentoo.org From: alexey+gentoo@asokolov.org Subject: Re: [gentoo-dev] RFC: Support for sys-kernel/dkms via a dkms.eclass in Gentoo Message-ID: In-Reply-To: <90d5839b-0092-44c8-a31a-09b7937ebef5@gentoo.org> References: <90d5839b-0092-44c8-a31a-09b7937ebef5@gentoo.org> Feedback-ID: 91776987:user:proton X-Pm-Message-ID: 329f1e3009fa3be00044d11b79aa9227d4a64ad3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b26bef2e-3126-4007-8580-cbbe90c51d11 X-Archives-Hash: 920c733b237b1d1191fabae2dfa6d58f =D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 4 =D0=BC=D0=B0=D1=80=D1=82= =D0=B0 2025 =D0=B3., 3:50 =D0=9F=D0=9F, Nowa Ammerlaan = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >=20 >=20 > Dear all, >=20 > This concept has turned out to be more controversial then I anticipated, > so I think it warrants broader discussion here on the mailing list. Let > me first explain some background information so everyone knows what we > are talking about, and then afterwards concretely discuss my idea for > implementing it in Gentoo. >=20 > The Dynamic Kernel Module System (DKMS, sys-kernel/dkms) is a > distro-agnostic framework for managing out-of-tree kernel modules. > You'll find it in most Linux distributions, though users usually do not > have to interact with it directly. In Gentoo this is packaged as > sys-kernel/dkms, though unlike most other package managers Portage > currently has no support for it. As such the usefulness of this package > is limited to some edge cases. >=20 > The operating principle of DKMS is simple. The package manager installs > the sources for one or more kernel modules to > /usr/src/$PACKAGE_NAME-$PACKAGE_VERSION/, and installs a configuration > file (dkms.conf) to the root of this source directory. The configuration > file describes which kernel modules are contained in this source > directory, how to build them, how to install them, as well as some metada= ta. >=20 > Then the dkms command line utility can be used to register (dkms add ... > ) these kernel sources in the local dkms tree (/var/lib/dkms). After > this the contained kernel modules can be built (dkms build ...) and > installed (dkms install ...). Compared to the alternative approach where > the package manager installs (pre-)built kernel modules directly to > /lib/modules/KV_FULL, the DKMS approach comes with several advantages: > - Via init system service, kernel modules can be automatically built and > installed when the system boots into some new kernel. > - Via kernel-install hook, kernel modules can be automatically built and > installed for multiple kernels in one go (kernel-install add-all). > - The above makes it possible to propagate updates of a kernel module to > an arbitrary number of kernels (and accompanying initramfs) without user > intervention. >=20 > End result is a "just works" experience when it comes to out-of-tree > kernel modules. This is something that in my opinion is currently sorely > lacking in Gentoo. Instead we currently have to fiddle with symlinks > (eselect kernel ...) or environment variables (KERNEL_DIR), and then > iteratively invoke the package manager multiple times. This is slow and > difficult to automate. And yes we could in theory create some solution > using multibuild.eclass and a KERNEL_TARGETS (similar to the > PYTHON_TARGETS). But this I think will be messy since the kernel has > significantly more slots to target then e.g. python, which means these > targets would have to be updated on every minor kernel version bump. Not > to mention that we would also have to support a wide variety of kernel > (source) packages. And then still we would not have the same level of > "just works" experience compared to dynamically compiling missing > modules while the system is booting, this we cannot reasonably achieve > using the package manager. >=20 > For this reason I propose to not invent our own new solution to improve > the situation, but instead adopt the proven industry standard solution: > DKMS. >=20 > I've opened a Pull Request (https://github.com/gentoo/gentoo/pull/40704) > with a working implementation of a dkms.eclass. The idea of the eclass > is relatively simple. We inherit linux-mod-r1.eclass so we don't have to > duplicate most of the setup and preparation logic. Then in the compile > phase we create a DKMS configuration file using the linux-mod-r1 modlist > and modargs defined by the ebuild, alternatively an existing upstream > DKMS configuration file may be used. The configuration file will contain > the users compiler etc. preference, *FLAGS and MAKEOPTS (i.e. > linux-mod-r1's MODULES_MAKEARGS), this ensures that we do not lose any > user customization in the process. Then in the install phase we find all > dkms.conf files and install those and the associated sources to > /usr/src/. Finally in the pkg_postinst and pkg_prerm phase we call dkms > to add/build/install/uninstall/unbuild/remove the contained kernel > modules. For convenience we also add a pkg_config function to call dkms > again to rebuild and reinstall the kernel modules. >=20 > Note that all of this is toggled by a new "dkms" USE flag, if this flag > is disabled then modules are built and installed as usual via > linux-mod-r1.eclass. This is intended to add a new option to Gentoo, not > to replace linux-mod-r1.eclass. A downside of this is that the existing > USE=3Dmodules-compress and USE=3Dmodules-sign are ineffective when USE=3D= dkms > is enabled. Though DKMS does support compressing and signing kernel > modules, which is configured via /etc/dkms/framework.conf. The default > is to compress kernel modules when the kernel modules currently in > /lib/modules/KV_FULL are also compressed, and to sign kernel modules > whenever it is able to do so (note a fix for DKMS to automatically > respect our MODULES_SIGN_KEY and MODULES_SIGN_CERT has already been > merged upstream). >=20 > Now I already know Sam and Ionen are not enthusiastic about this idea, > they are concerned about having to support two paths to achieve similar > ends and are not (yet) convinced of the added value of the DKMS pathway. > But I'd love to hear more opinions. If really everyone hates this then > I'll drop it, but currently I am still convinced this is useful and > worth the effort. Because DKMS support adds a "just works" level of > experience that we cannot reasonably achieve with the package manager > and because it is the industry standard solution and thus is often > tested and supported by kernel modules upstream. >=20 > Please find the proposed eclass, as well as implementation in a bunch of > ebuilds, in my PR: https://github.com/gentoo/gentoo/pull/40704 > I could send it to the mailinglist, but it's 41 commits large and I > don't want to spam everyone. >=20 > Best regards, > Nowa >=20 Thanks for this! DKMS is the only feature which I'm still missing from times when I was usin= g Debian/Ubuntu. The @module-rebuild is not as good.