From: Ionen Wolkens <ionen@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public
Date: Fri, 14 Mar 2025 23:56:37 -0400 [thread overview]
Message-ID: <Z9T6dcd_djSXg6VX@eversor> (raw)
In-Reply-To: <655147fe-ed05-4b09-9f73-c1765fe6c841@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]
On Fri, Mar 14, 2025 at 08:47:37PM +0100, Nowa Ammerlaan wrote:
> On 14/03/2025 17:23, Ionen Wolkens wrote:
> > On Fri, Mar 14, 2025 at 01:48:50PM +0100, Nowa Ammerlaan wrote:
> >> eclass/linux-mod-r1.eclass | 7 +++----
> >
> > ftr my opinion on this hasn't changed since the beginning, I was hoping
> > that the idea would be scrapped early rather than more work being put
> > into it.
>
> I noted your initial concerns and sam's hesitation, and would have
> stopped pursuing this further had I not also received positive feedback
> convincing me that there is indeed some demand for adding DKMS support
> as an option. I had hoped that the final version of the new eclass,
> being significantly cleaner and more robust, would have changed your mind.
>
> > 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.
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.
>
> Adding support for the DKMS pathway to only a subset of kernel modules
> is bound to be lead to a confusing end result, so that is not really a
> state in which I want to merge this in.
>
> Best regards,
> Nowa
>
--
ionen
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-03-15 3:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 12:48 [gentoo-dev] [PATCH 1/5] use.desc: document new dkms flag Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 2/5] profiles: mask dkms flag where not available Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 3/5] linux-mod-r1.eclass: move modlist processing into separate func Nowa Ammerlaan
2025-03-14 12:48 ` [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public Nowa Ammerlaan
2025-03-14 16:23 ` Ionen Wolkens
2025-03-14 19:47 ` Nowa Ammerlaan
2025-03-15 3:56 ` Ionen Wolkens [this message]
2025-03-17 10:11 ` Nowa Ammerlaan
2025-03-17 10:25 ` Alexey Sokolov
2025-03-18 3:14 ` [gentoo-dev] " Duncan
2025-03-19 0:34 ` Ionen Wolkens
2025-03-19 0:56 ` Ionen Wolkens
2025-03-19 1:07 ` Ionen Wolkens
2025-03-19 7:57 ` Nowa Ammerlaan
2025-03-19 8:48 ` Ionen Wolkens
2025-03-19 12:41 ` Nowa Ammerlaan
2025-03-19 22:10 ` Sam James
2025-03-19 22:37 ` Eli Schwartz
2025-03-20 8:25 ` Nowa Ammerlaan
2025-03-20 8:12 ` Nowa Ammerlaan
2025-03-19 3:05 ` Ionen Wolkens
2025-03-19 22:11 ` Sam James
2025-03-17 16:23 ` [gentoo-dev] " Eli Schwartz
2025-03-14 12:48 ` [gentoo-dev] [PATCH 5/5] dkms.eclass: introduce new eclass Nowa Ammerlaan
2025-03-14 15:34 ` Alexey Sokolov
2025-03-14 15:44 ` Nowa Ammerlaan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z9T6dcd_djSXg6VX@eversor \
--to=ionen@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox