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 7E8611584F2 for ; Mon, 17 Mar 2025 10:26:32 +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 6615F3432A1 for ; Mon, 17 Mar 2025 10:26:32 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id BD5011103E2; Mon, 17 Mar 2025 10:25:49 +0000 (UTC) Received: from mail-10627.protonmail.ch (mail-10627.protonmail.ch [79.135.106.27]) (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 D2F7E11037F for ; Mon, 17 Mar 2025 10:25:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asokolov.org; s=protonmail3; t=1742207142; x=1742466342; bh=USlK7M6kuSWAA0ZnkbyU3xxey/Ppha0+QdDKaC4Sfjc=; 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=GTS1AIlvAbJglb5EYkeV8PdCHtWSMCONRiESlic2soefKc4an78KbCe8o8QCksn7N LckbBo/6xIGHtm3e+2HQv609Vzm33LzV0xDS/qDBdrw8DsYbMVs0eyeqJCfnBu2nM9 2bivv48aqpXTmmJwTs14e+6gWfpJrNXl0bzu7m09wt8SQLBccVFhPsuyElL4KpqYbK up6SBmL/L49F9rB9Fcm1xsKWhl+QU76jWCy0vuAmS3e1XmIcmOTFWmA39NFlXVhsht tLyTDrsylgA4paSYhLWmXwKvLZh51Wt0Dj6963r4BKy6HPjXZusTKRTKqqoer4l50A 0kGR4KQYBBacw== Date: Mon, 17 Mar 2025 10:25:37 +0000 To: gentoo-dev@lists.gentoo.org From: Alexey Sokolov Subject: Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public Message-ID: <856e8959-32be-4338-885c-0f3d70fcf6b5@asokolov.org> In-Reply-To: <487ddd00-aabe-4c9b-a312-a541a1ef61f1@gentoo.org> References: <20250314124851.716771-1-nowa@gentoo.org> <20250314124851.716771-4-nowa@gentoo.org> <655147fe-ed05-4b09-9f73-c1765fe6c841@gentoo.org> <487ddd00-aabe-4c9b-a312-a541a1ef61f1@gentoo.org> Feedback-ID: 91776987:user:proton X-Pm-Message-ID: e013e3fc6357d4c7fad2ae6ec27942b0acac201f 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: eca35b57-c5b7-45d5-8667-a35305c01704 X-Archives-Hash: 7f558e0316749ef3a033774d4e9c986c 17.03.2025 10:11, Nowa Ammerlaan =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On 15/03/2025 04:56, Ionen Wolkens wrote: >>>> This just feels like a messy half-solution that we're better off >>>> without. >>>> >>>> So NACK from me, both for linux-mod-r1 and adding support to my >>>> packages like nvidia-drivers. >>>> >>>> Not that I'll revert if it gets merged anyway. >>> Is there anything I can say or do to convince you otherwise? I honestly >>> believe that I have addressed all concerns that have been raised so far= . >> 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. >> >> 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. > I really don't see how we can reasonably solve this problem via eclass > given that the number of possible kernel targets is way bigger then for > example multilib, PYTHON_TARGETS etc. Plus we also have to account for > kernels that are not built and installed by the package manager. In my > opinion what you propose here is unnecessarily complex and I really > doubt it will work. > >> 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?). >> >> 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). >> >> 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. > Well I don't know what to say other then that I strongly disagree. This > is not hacky, DKMS is the standard solution in many many other > distributions and it works pretty well there. I really don't understand > why it could not work equally well for us. In fact, I'll turn this > around and say that our current solution with the slotted > virtual/dist-kernel is hacky. It works poorly mainly because there is no > relation between the actual kernel target and the installed slot of the > virtual (other then a warning if the eclass detects a mismatch). This > makes the binpkg situation here a mess. Downgrading is difficult. > Portage is extremely slow in resolving all these slot dependencies. And > all of this is not intuitive and very confusing for new users. > > I do not agree that these problems are not important. Out of tree kernel > modules are essential to many systems, and therefore this should "just > work". Sure it's a fixable problem when it breaks, but it's annoying and > requires manual intervention. Gentoo deserves better, and we can very > easily make it better by doing what loads of other distributions are > also doing (i.e. use DKMS). > > I am **not** proposing this as an interim solution (I hate interim > solutions), I am proposing this as a permanent alternative method of > managing kernel modules where the package manager is less involved > (while still retaining user compiler/flag preferences etc). Reworking > linux-info so it can support multiple targets is still possible, these > things are not mutually exclusive (though I still believe DKMS is the > better solution even if we do rework the eclasses). > > I really do not understand why you are so strongly opposed to this and > use as your only arguments that a) the problem being solved is not > important and b) the problem could be solved by some complex and vague > other solution that does not currently exist. > > > I had really hoped to receive more comments on my earlier RFC. Because > now I still feel like it's just you and me disagreeing and we are > getting nowhere. I really do want to know what others think so I can > make a better judgment on whether or not my idea is really this crazy > and if I should just shut up about it or not (so dear reader if you have > an opinion then please share). > > Best regards, > Nowa > > > Well, I don't know whether my opinion counts for much, but count me in=20 to add USE=3D"dkms" to my make.conf the moment this is merged. I do use=20 more than 1 kernel and the current situation with @module-rebuild often=20 makes me boot to a kernel without all the required modules, so I end up=20 without my home directory after a reboot because portage randomly=20 decided to not rebuild zfs module for certain reasons. I haven't looked at the implementation in the PR, so can only comment=20 that DKMS on Ubuntu worked very well, back before I switched to Gentoo,=20 specifically because of how DKMS handled nvidia drivers.