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 137B11584F2 for ; Mon, 17 Mar 2025 16:24:34 +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 EC8A734333A for ; Mon, 17 Mar 2025 16:24:33 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id A54071103E2; Mon, 17 Mar 2025 16:23:51 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 E7EC311037F for ; Mon, 17 Mar 2025 16:23:50 +0000 (UTC) Received: from [IPV6:2603:6011:3f0:6f00::12ac] (unknown [IPv6:2603:6011:3f0:6f00::12ac]) (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) (Authenticated sender: eschwartz) by smtp.gentoo.org (Postfix) with ESMTPSA id 93DFF3432B2 for ; Mon, 17 Mar 2025 16:23:50 +0000 (UTC) Message-ID: Date: Mon, 17 Mar 2025 12:23:46 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public To: gentoo-dev@lists.gentoo.org References: <20250314124851.716771-1-nowa@gentoo.org> <20250314124851.716771-4-nowa@gentoo.org> <655147fe-ed05-4b09-9f73-c1765fe6c841@gentoo.org> Content-Language: en-US From: Eli Schwartz Autocrypt: addr=eschwartz@gentoo.org; keydata= xjMEZmeRNBYJKwYBBAHaRw8BAQdAYNZ7pUDWhx1i2f3p6L2ZLu4FcY18UoeGC04Gq/khqwfN I0VsaSBTY2h3YXJ0eiA8ZXNjaHdhcnR6QGdlbnRvby5vcmc+wpYEExYKAD4WIQTvUdMIsc4j CIi+DYTqQj6ToWND8QUCZoRL+gIbAwUJBKKGAAULCQgHAwUVCgkICwUWAgMBAAIeBQIXgAAK CRDqQj6ToWND8aB5AP9r4kB691nNtNwKkdRiOdl7/k6WYzokvHvDamXxRJ0I+gEAjZqR5V8y mfR3fy2Z+r2Joeqdt3CIv5IwPs64spBvigLOOARmZ5E0EgorBgEEAZdVAQUBAQdATT46Z06b 1X9xjXFCYFxmq/Tj3tSEKZInDWTpoHQp4l8DAQgHwn4EGBYKACYWIQTvUdMIsc4jCIi+DYTq Qj6ToWND8QUCZmeRNAIbDAUJBKKGAAAKCRDqQj6ToWND8a2RAP40KPfbfoiZAJW5boFmFJ3G TUBDJRh9CWHyaPqq2PN+0wD/R07oLzfnJUN209mzi9TuTuHjeZybysyqXSw4MAxkMAY= In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------sRM5a0TlcLYonVnE091w9DIX" X-Archives-Salt: afdaea4f-3f23-4d85-8024-7edf4c22fa16 X-Archives-Hash: 2fc0ed64520e6bf9f72e6d0d41ad017b This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------sRM5a0TlcLYonVnE091w9DIX Content-Type: multipart/mixed; boundary="------------J2quNGboU2PfKBqEBBlyiAk0"; protected-headers="v1" From: Eli Schwartz To: gentoo-dev@lists.gentoo.org Message-ID: Subject: Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public References: <20250314124851.716771-1-nowa@gentoo.org> <20250314124851.716771-4-nowa@gentoo.org> <655147fe-ed05-4b09-9f73-c1765fe6c841@gentoo.org> In-Reply-To: --------------J2quNGboU2PfKBqEBBlyiAk0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/14/25 11:56 PM, Ionen Wolkens wrote: > I don't think so, it's more the idea in itself that I dislike than the > implementation. Not that the latter helps with its kind of unintended > hacked-on-top linux-mod-r1 implementation that (as you know) not all > ebuilds can use right now... but I generally want to avoid requesting > improvements given it's unlikely it'd change how I feel about this. So what I'm hearing from this is that you simply dislike sys-kernel/dkms itself, and would be okay having it treecleaned as you don't think anyone should use it, but out of respect for the fact that someone else packaged it and cares about it are refraining from submitting a treeclean request. However, you are taking the opportunity of eclass review to register your conscientious objections to the existence of the dkms software, and stating your reservations about anyone making use of it for example in an eclass on the grounds of the aforementioned skepticism that the software should exist / be packaged. I can respect that opinion, but it's also going to influence my view of this discussion, namely, that when you critique this proposal, your critique isn't actually a critique of the proposal, but a statement that in a distro about choice, your choice is the other choice, not this choic= e. I think there's room in Gentoo for both choices, as long as the choices are implemented well for their respective users, which I think that this dkms proposal is. > As noted on PR, *if* we really want to support rebuilding for multiple > kernels it's something that could be done with a linux-mod-r2 eclass > rather than dkms (not that it wouldn't require work because of the way > current linux-info works, and some ebuilds would need to be adapted in > a multilib kinda way), and I'm not convinced the "rebuild at boot" is > really meaningful esp. with distribution kernels that are controlled > by the PM. >=20 > PM limitations could be improved in future EAPIs, like a way to have > proper hooks for modules and initramfs rebuilding so that we wouldn't > have to rely on (not really slot-able) virtual/dist-kernel and > duplicated initramfs generation. It could potentially also clean old > modules safely then. Such hooks system would also be handy for other > things like rebuilding gtk icon cache and such rather than doing it > per-ebuild (we may already have a bug for this somewhere?). "proper hooks" would work exactly like pkg_postinst in that you are able to run gtk icon cache regeneration via a PM hook after a package is installed. Other package managers have explored the same design space, so we can know that it works, and also *how* it works. The defining nature of a PM hook as opposed to a pkg_postinst command is that it operates per installation session (a complete emerge run) as opposed to running once per package, and that it is injected into packages by the PM rather than requiring each package to add code to pkg_postinst. It will not and cannot provide much of anything in the way of additional facilities above and beyond pkg_postinst in terms of targeting other kernel targets outside of virtual/dist-kernel. It's possible to trigger an action based on installing a /boot/vmlinuz-* or /lib/modules/*/ filesystem entry recorded in the vdb inside CONTENTS, but that helps nearly not at all, given the extreme frequency of users using something other than dist-kernel, such as gentoo-sources. The gentoo-sources kernel is not even installed via portage, it is inconceivable that a future EAPI hook system could run a PM hook in response to `make install modules_install`. But fine, let's ignore all that. What command would you like to run in such a PM hook? Other distros that have such hooks, run... `dkms install`. :) Because it has to trigger on installing a new kernel, and because the whole point of a hook is to do things *outside* of an individual package recipe, which means it doesn't have access to the environment file and cannot know how to build a particular module unless there's a PM-independent framework such as dkms to do so. Since PM hooks give you nothing but the ability to run the same action, triggered by multiple packages, only once instead of once per package, it logically infers that you can still upgrade linux-mod-r1 today, without waiting for "PM hooks" to materialize. Simply... have linux-mod-r1 execute a pkg_postinst that loops over all installed kernels and builds for all of them. This is strictly a subset of what "PM hooks" can do, but only because "PM hooks" would also run whenever a kernel is installed or upgraded, and gentoo-kernel-*.ebuild cannot recursively trigger emerge @module-rebuild (nor could "PM hooks", but "PM hooks" could trigger `dkms install` if module sources were installed to the dkms framework, which you have rejected as hacky). > And I don't feel that this is all important/urgent enough that we need > to establish (hacky) dkms usage in the interim as a "better than > nothing" solution. *Vast* majority of users only care about one kernel,= > at most the old just need to be able to boot into a console to fix > issues if something went wrong (that nvidia-drivers may mismatch with > userspace is not great, but not getting GPU acceleration is not the > the end of the world in that situation). >=20 > Not great but, if one rare user really needs to rebuild for multiple > kernels, there are still (unintuitive) ways to do that in the interim > such as emerging modules multiple times by pointing to different > linux sources -- but again emphasis on that not really many need this. Sorry but I do not understand at all where you are coming from. The dkms proposal is presenting itself as a possible alternative and arguing that it's stable, reliable, robust and a permanent option with no intention of ever being declared obsolete and being removed from ::gentoo. It is indisputable that there are people who regard dkms as value-add in its own right -- that is why there is a "sys-kernel/dkms" package in the first place, you know -- and the people in that camp will not accept any other solution as answering their needs, which I think is a compelling proof that this isn't "a hacky interim solution that is better than nothing" Which is total misrepresentation of the entire discussion. Moreover, you're arguing how dkms is "hacky interim solutions" and refusing to consider it and instead saying that there are "still (unintuitive) ways to do that in the interim" and then you unenthusiastically talk about something you're plainly not at all convinced about either. How is it that you can tell someone who claims to be proposing a non-hacky solution: """ no, you're wrong, your solution is in fact a hack actually. I don't like it, hacks are gross and we shouldn't add hacks. Instead, I propose a different hack which people should use instead. Maybe one day someone will propose an unspecified PMS solution for this. """ No. Sorry. You're the one proposing hacky interim usage as a "better than nothing" solution. Building modules inside a package does have significant usefulness for the purpose of e.g. rolling out cached binary packages to a fleet of boxes, but I can't accept the notion that hackily changing the kernel sources and repeatedly running `emerge @module-rebuild` is a good option either as an interim or a permanent approach to build modules for multiple kernels. --=20 Eli Schwartz --------------J2quNGboU2PfKBqEBBlyiAk0-- --------------sRM5a0TlcLYonVnE091w9DIX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCZ9hMkwUDAAAAAAAKCRCEp9ErcA0vV6D4 AQCoopFefILG7c6cd+j5APC/wnApAVoqi7J/+ouIjQKA1AD/cnkXmClNPfezOIlCuuyT8Iy7yl2H qfuqwxZlUaAKBwk= =UbPi -----END PGP SIGNATURE----- --------------sRM5a0TlcLYonVnE091w9DIX--