[gentoo-dev] [PATCH 1/5] use.desc: document new dkms flag

[gentoo-dev] [PATCH 1/5] use.desc: document new dkms flag

[Nowa Ammerlaan]

Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
---
 profiles/use.desc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/use.desc b/profiles/use.desc
index 36468b321ddb..6e8329009947 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -66,6 +66,7 @@ dedicated - Add support for dedicated game servers (some packages do not provide
 dga - Add DGA (Direct Graphic Access) support for X
 dist-kernel - Enable subslot rebuilds on Distribution Kernel upgrades
 djvu - Support DjVu, a PDF-like document format esp. suited for scanned documents
+dkms - Manage external kernel modules with sys-kernel/dkms
 doc - Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
 dri - Enable direct rendering: used for accelerated 3D and some 2D, like DMA
 dts - Enable DTS Coherent Acoustics decoder support
-- 
2.48.1

[gentoo-dev] [PATCH 2/5] profiles: mask dkms flag where not available

[Nowa Ammerlaan]

and stable mask for now

Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
---
 profiles/arch/amd64/use.mask        | 4 ++++
 profiles/arch/amd64/use.stable.mask | 4 ++++
 profiles/arch/arm64/use.mask        | 4 ++++
 profiles/arch/arm64/use.stable.mask | 4 ++++
 profiles/arch/base/use.mask         | 4 ++++
 profiles/arch/x86/use.mask          | 4 ++++
 profiles/arch/x86/use.stable.mask   | 4 ++++
 7 files changed, 28 insertions(+)

diff --git a/profiles/arch/amd64/use.mask b/profiles/arch/amd64/use.mask
index d4ed8ec4f047..6f96ddd09fd4 100644
--- a/profiles/arch/amd64/use.mask
+++ b/profiles/arch/amd64/use.mask
@@ -4,6 +4,10 @@
 # Unmask the flag which corresponds to ARCH.
 -amd64
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-22)
+# DKMS is available here
+-dkms
+
 # Thomas Bettler <thomas.bettler@gmail.com> (2024-11-04)
 # media-libs/tiff only keyworded on amd64
 -lerc
diff --git a/profiles/arch/amd64/use.stable.mask b/profiles/arch/amd64/use.stable.mask
index 71ed679097c9..845db0e701ad 100644
--- a/profiles/arch/amd64/use.stable.mask
+++ b/profiles/arch/amd64/use.stable.mask
@@ -4,6 +4,10 @@
 # New entries go on top.
 # Please use the same syntax as in use.mask.
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-26)
+# Stable mask until things have settled and the documentation is done.
+dkms
+
 # Paul Zander <negril.nx+gentoo@gmail.com> (2023-11-17)
 # ROCm/HIP is not suitable for stabilization.
 hip
diff --git a/profiles/arch/arm64/use.mask b/profiles/arch/arm64/use.mask
index 3ff27eb7078e..e057af7c34b3 100644
--- a/profiles/arch/arm64/use.mask
+++ b/profiles/arch/arm64/use.mask
@@ -4,6 +4,10 @@
 # Unmask the flag which corresponds to ARCH.
 -arm64
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-22)
+# DKMS is available here
+-dkms
+
 # Sam James <sam@gentoo.org> (2025-02-19)
 # x11-drivers/xf86-input-wacom is available here
 -input_devices_wacom
diff --git a/profiles/arch/arm64/use.stable.mask b/profiles/arch/arm64/use.stable.mask
index b763434dcbec..fe481454ebc2 100644
--- a/profiles/arch/arm64/use.stable.mask
+++ b/profiles/arch/arm64/use.stable.mask
@@ -5,6 +5,10 @@
 # New entries go on top.
 # Please use the same syntax as in use.mask.
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-26)
+# Stable mask until things have settled and the documentation is done.
+dkms
+
 # Matt Turner <mattst88@gentoo.org> (2024-05-10)
 # x11-drivers/xf86-video-vmware is not stable yet
 video_cards_vmware
diff --git a/profiles/arch/base/use.mask b/profiles/arch/base/use.mask
index 864930eb31bd..8e469b828f70 100644
--- a/profiles/arch/base/use.mask
+++ b/profiles/arch/base/use.mask
@@ -1,6 +1,10 @@
 # Copyright 1999-2025 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-22)
+# DKMS is not available everywhere yet
+dkms
+
 # Thomas Bettler <thomas.bettler@gmail.com> (2024-11-04)
 # media-libs/tiff only keyworded on amd64
 lerc
diff --git a/profiles/arch/x86/use.mask b/profiles/arch/x86/use.mask
index 0da67bc70068..771c12145d95 100644
--- a/profiles/arch/x86/use.mask
+++ b/profiles/arch/x86/use.mask
@@ -4,6 +4,10 @@
 # Unmask the flag which corresponds to ARCH.
 -x86
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-22)
+# DKMS is available here
+-dkms
+
 # Paul Zander <negril.nx+gentoo@gmail.com> (2024-04-14)
 # media-libs/quirc is keyworded on amd64
 -quirc
diff --git a/profiles/arch/x86/use.stable.mask b/profiles/arch/x86/use.stable.mask
index f791b36944bd..638c0fb84e0a 100644
--- a/profiles/arch/x86/use.stable.mask
+++ b/profiles/arch/x86/use.stable.mask
@@ -4,6 +4,10 @@
 # New entries go on top.
 # Please use the same syntax as in use.mask.
 
+# Nowa Ammerlaan <nowa@gentoo.org> (2025-02-26)
+# Stable mask until things have settled and the documentation is done.
+dkms
+
 # Andreas Sturmlechner <asturm@gentoo.org> (2025-03-07)
 # KDE Frameworks is not stable
 kde
-- 
2.48.1

[gentoo-dev] [PATCH 3/5] linux-mod-r1.eclass: move modlist processing into separate func

[Nowa Ammerlaan]

Does not really change anything but avoids duplication in dkms.eclass

Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
---
 eclass/linux-mod-r1.eclass | 78 +++++++++++++++++++++++++-------------
 1 file changed, 51 insertions(+), 27 deletions(-)

diff --git a/eclass/linux-mod-r1.eclass b/eclass/linux-mod-r1.eclass
index 16c280219ef8..fd83324fa35d 100644
--- a/eclass/linux-mod-r1.eclass
+++ b/eclass/linux-mod-r1.eclass
@@ -412,46 +412,20 @@ linux-mod-r1_src_compile() {
 	debug-print-function ${FUNCNAME} "$@"
 	_modules_check_function ${#} 0 0 || return 0
 
-	[[ ${modlist@a} == *a* && ${#modlist[@]} -gt 0 ]] ||
-		die "${FUNCNAME[0]} was called without a 'modlist' array"
-
 	# run this again to verify built files access with src_compile's user
 	_modules_sanity_kernelbuilt
 
-	local -a emakeargs=( "${MODULES_MAKEARGS[@]}" )
-	[[ ${modargs@a} == *a* ]] && emakeargs+=( "${modargs[@]}" )
+	modules_process_modlist
 
 	local -A built=()
 	local build mod name target
 	for mod in "${modlist[@]}"; do
-		# note modlist was not made an associative array ([name]=) to preserve
-		# ordering, but is still using = to improve readability
 		name=${mod%%=*}
-		[[ -n ${name} && ${name} != *:* ]] || die "invalid mod entry '${mod}'"
-
-		# 0:install-dir 1:source-dir 2:build-dir 3:make-target(s)
 		mod=${mod#"${name}"}
 		IFS=: read -ra mod <<<"${mod#=}"
-		[[ ${#mod[@]} -le 4 ]] || die "too many ':' in ${name}'s modlist"
-
-		[[ ${mod[1]:=${PWD}} != /* ]] && mod[1]=${PWD}/${mod[1]}
-		[[ ${mod[2]:=${mod[1]}} != /* ]] && mod[2]=${PWD}/${mod[2]}
-		_MODULES_INSTALL[${mod[2]}/${name}.ko]=${mod[0]:-extra}
 
 		pushd "${mod[1]}" >/dev/null || die
 
-		if [[ -z ${mod[3]} ]]; then
-			# guess between commonly used targets if none given, fallback to
-			# an empty target without trying to see the error output
-			for target in module{s,} "${name}".ko default all; do
-				nonfatal emake "${emakeargs[@]}" -q "${target}" &>/dev/null
-				if [[ ${?} -eq 1 ]]; then
-					mod[3]=${target}
-					break
-				fi
-			done
-		fi
-
 		# sometime modules are all from same source dir and built all at once,
 		# make will not rebuild either way but can skip the unnecessary noise
 		build=
@@ -527,6 +501,56 @@ linux-mod-r1_pkg_postinst() {
 		eqawarn "QA Notice: neither linux-mod-r1_src_install nor modules_post_process were used"
 }
 
+# @FUNCTION: modules_process_modlist
+# @USAGE:
+# @DESCRIPTION:
+# Process the ebuilds modlist. Sets the default values for each
+# module in the modlist array in preparation for the module build.
+modules_process_modlist() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	[[ ${modlist@a} == *a* && ${#modlist[@]} -gt 0 ]] ||
+		die "${FUNCNAME[0]} was called without a 'modlist' array"
+
+	emakeargs=( "${MODULES_MAKEARGS[@]}" )
+	[[ ${modargs@a} == *a* ]] && emakeargs+=( "${modargs[@]}" )
+
+	local index mod name target
+	for index in "${!modlist[@]}"; do
+		mod=${modlist[index]}
+		# note modlist was not made an associative array ([name]=) to preserve
+		# ordering, but is still using = to improve readability
+		name=${mod%%=*}
+		[[ -n ${name} && ${name} != *:* ]] || die "invalid mod entry '${mod}'"
+
+		# 0:install-dir 1:source-dir 2:build-dir 3:make-target(s)
+		mod=${mod#"${name}"}
+		IFS=: read -ra mod <<<"${mod#=}"
+		[[ ${#mod[@]} -le 4 ]] || die "too many ':' in ${name}'s modlist"
+
+		[[ ${mod[1]:=${PWD}} != /* ]] && mod[1]=${PWD}/${mod[1]}
+		[[ ${mod[2]:=${mod[1]}} != /* ]] && mod[2]=${PWD}/${mod[2]}
+		_MODULES_INSTALL[${mod[2]}/${name}.ko]=${mod[0]:-extra}
+
+		pushd "${mod[1]}" >/dev/null || die
+
+		if [[ -z ${mod[3]} ]]; then
+			# guess between commonly used targets if none given, fallback to
+			# an empty target without trying to see the error output
+			for target in module{s,} "${name}".ko default all; do
+				nonfatal emake "${emakeargs[@]}" -q "${target}" &>/dev/null
+				if [[ ${?} -eq 1 ]]; then
+					mod[3]=${target}
+					break
+				fi
+			done
+		fi
+
+		modlist[index]="${name}=${mod[0]}:${mod[1]}:${mod[2]}:${mod[3]}"
+		popd >/dev/null || die
+	done
+}
+
 # @FUNCTION: linux_domodule
 # @USAGE: <module>...
 # @DESCRIPTION:
-- 
2.48.1

[gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

so we can re-use this function in dkms.eclass.

Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
---
 eclass/linux-mod-r1.eclass | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/eclass/linux-mod-r1.eclass b/eclass/linux-mod-r1.eclass
index fd83324fa35d..d736f48d679e 100644
--- a/eclass/linux-mod-r1.eclass
+++ b/eclass/linux-mod-r1.eclass
@@ -625,7 +625,7 @@ modules_post_process() {
 	# dracut omit files that *hopefully* prevent this
 #	_modules_process_depmod.d "${mods[@]##*/}"
 
-	_modules_process_dracut.conf.d "${mods[@]##*/}"
+	modules_process_dracut.conf.d "${mods[@]##*/}"
 	_modules_process_strip "${mods[@]}"
 	_modules_process_sign "${mods[@]}"
 	_modules_sanity_modversion "${mods[@]}" # after strip/sign in case broke it
@@ -967,13 +967,12 @@ _modules_process_depmod.d() {
 	)
 }
 
-# @FUNCTION: _modules_process_dracut.conf.d
+# @FUNCTION: modules_process_dracut.conf.d
 # @USAGE: <module>...
-# @INTERNAL
 # @DESCRIPTION:
 # Create dracut.conf.d snippet defining if module should be included in the
 # initramfs.
-_modules_process_dracut.conf.d() {
+modules_process_dracut.conf.d() {
 	(
 		insinto /usr/lib/dracut/dracut.conf.d
 		[[ ${MODULES_INITRAMFS_IUSE} ]] && use ${MODULES_INITRAMFS_IUSE#+} &&
-- 
2.48.1

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

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.

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.
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

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.

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

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- 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 --]

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

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

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Alexey Sokolov]

17.03.2025 10:11, Nowa Ammerlaan пишет:
> 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 
to add USE="dkms" to my make.conf the moment this is merged. I do use 
more than 1 kernel and the current situation with @module-rebuild often 
makes me boot to a kernel without all the required modules, so I end up 
without my home directory after a reboot because portage randomly 
decided to not rebuild zfs module for certain reasons.

I haven't looked at the implementation in the PR, so can only comment 
that DKMS on Ubuntu worked very well, back before I switched to Gentoo, 
specifically because of how DKMS handled nvidia drivers.

[gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Duncan]

Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:

> I had really hoped to receive more comments on my earlier RFC. [...]
> 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).

So because I carried over my own already "works for me" kernel maintenance 
scripts from Mandrake when I switched in 2004 and have continued 
maintaining and using them over the decades since, I normally try to stay 
out of Gentoo kernel packaging discussion. But given both the above 
explicit invitation and that as I've read the thread a thought occurred to 
me...

First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
general it should be reasonably supported in Gentoo unless it simply 
doesn't make sense (note that "doesn't make sense" can also include the 
case of simply no one stepping up to do it, not the case here).

But, the thought that occurred to me reading the thread, was that there 
are obvious parallels between this and another very significant and 
controversial now "cross distro standard solution" (which I guess I don't 
need to name explicitly).

As there, I believe "the Gentoo approach" should (again assuming developer 
willingness to do the work, seemingly the case here) make it available as 
an additional integrated *option*, while keeping the current Gentoo option 
as well.

So I support DKMS integration /as/ /an/ /option/.

That said, in keeping with my normal policy I'll avoid comment on whether 
this specific implementation is the best way to do it, vs. something else 
(which might actually be as simple as a good dkms gentoo-wiki page, or to 
complete the parallel, may be complex enough to justify installation 
handbook integration).

(Meanwhile, in terms of my personal dkms experience, while my normal 
kernel maintenance scripts don't use it, I ran across it in an upstream 
kernel bug tracing discussion at one point and recall being rather 
confused, having to ddg it, etc.  Once I figured out what it actually was 
I had the context necessary to decide I was better off slightly modifying 
my existing approach than trying to learn something new "that probably 
made binary-distro assumptions I'd have to work around anyway".  If it was 
well integrated into Gentoo including documentation I'd have probably at 
least have heard about it, and would likely have had a much better idea 
whether and how it would mesh with my own kernel maintenance scripts.  So 
that's why, as an accepted cross-distro standard solution, I'm in favor of 
integrating it, even if I may or may not be able to personally take 
advantage of that given my otherwise independent kernel scripts solution.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]

On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
> 
> > I had really hoped to receive more comments on my earlier RFC. [...]
> > 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).
> 
> So because I carried over my own already "works for me" kernel maintenance 
> scripts from Mandrake when I switched in 2004 and have continued 
> maintaining and using them over the decades since, I normally try to stay 
> out of Gentoo kernel packaging discussion. But given both the above 
> explicit invitation and that as I've read the thread a thought occurred to 
> me...
> 
> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> general it should be reasonably supported in Gentoo unless it simply 
> doesn't make sense (note that "doesn't make sense" can also include the 
> case of simply no one stepping up to do it, not the case here).
> 
> But, the thought that occurred to me reading the thread, was that there 
> are obvious parallels between this and another very significant and 
> controversial now "cross distro standard solution" (which I guess I don't 
> need to name explicitly).
> 
> As there, I believe "the Gentoo approach" should (again assuming developer 
> willingness to do the work, seemingly the case here) make it available as 
> an additional integrated *option*, while keeping the current Gentoo option 
> as well.
> 
> So I support DKMS integration /as/ /an/ /option/.

If anything, if go forward with this, I'd rather that it be with the
plan to (eventually) either make it the default after enough testing
and then later drop support for the old way entirely (then merge the
eclasses), or revert if we think it's no good.

One of the thing I did not like here is the idea to gain more ways
to do the same thing that need to be tested to ensure some quality.
Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
some path or something else and I don't test it on bump, then I push
a broken package for all dkms users until someone reports it. Would
even need to boot with it to be sure.

It's nice to have choices in general, but still need to draw some
lines to keep things maintainable.

And if picking, in the end do we pick an option that requires to
install sources and (imo) adds very little, or let the PM (that has
access to sources unlike binary distros) handle it (with full control
for handling issues) just like for dist kernels and improve on that
as needed?

Either way, as I said initially, I won't revert if this gets merged
(even if optional forever). Just stating that I don't like it and
probably won't offer real support, not blocking it.

wrt merging eclasses, could add that I wasn't really against the
support for this being in linux-mod-r1 directly except for the part
where it did not work when not using modlist being confusing, in the
end I'd probably just have asked for Nowa to add themselves as
maintainer.

On a related note about modlist, I've been semi-regretting keeping that
modlist-type idea from the original linux-mod eclass and felt that a
simple emake wrapper (incl. modules args) for all packages "might" have
been better and easier to use for ebuilds and not miss modules on bump
and had been pondering "potential" deprecation in the future (not that
I had really explored that idea yet, would need to check packages).
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 3989 bytes --]

On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
> > Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
> > 
> > > I had really hoped to receive more comments on my earlier RFC. [...]
> > > 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).
> > 
> > So because I carried over my own already "works for me" kernel maintenance 
> > scripts from Mandrake when I switched in 2004 and have continued 
> > maintaining and using them over the decades since, I normally try to stay 
> > out of Gentoo kernel packaging discussion. But given both the above 
> > explicit invitation and that as I've read the thread a thought occurred to 
> > me...
> > 
> > First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> > general it should be reasonably supported in Gentoo unless it simply 
> > doesn't make sense (note that "doesn't make sense" can also include the 
> > case of simply no one stepping up to do it, not the case here).
> > 
> > But, the thought that occurred to me reading the thread, was that there 
> > are obvious parallels between this and another very significant and 
> > controversial now "cross distro standard solution" (which I guess I don't 
> > need to name explicitly).
> > 
> > As there, I believe "the Gentoo approach" should (again assuming developer 
> > willingness to do the work, seemingly the case here) make it available as 
> > an additional integrated *option*, while keeping the current Gentoo option 
> > as well.
> > 
> > So I support DKMS integration /as/ /an/ /option/.
> 
> If anything, if go forward with this, I'd rather that it be with the
> plan to (eventually) either make it the default after enough testing
> and then later drop support for the old way entirely (then merge the
> eclasses), or revert if we think it's no good.
> 
> One of the thing I did not like here is the idea to gain more ways
> to do the same thing that need to be tested to ensure some quality.
> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
> some path or something else and I don't test it on bump, then I push
> a broken package for all dkms users until someone reports it. Would
> even need to boot with it to be sure.
> 
> It's nice to have choices in general, but still need to draw some
> lines to keep things maintainable.
> 
> And if picking, in the end do we pick an option that requires to
> install sources and (imo) adds very little, or let the PM (that has
> access to sources unlike binary distros) handle it (with full control
> for handling issues) just like for dist kernels and improve on that
> as needed?
> 
> Either way, as I said initially, I won't revert if this gets merged
> (even if optional forever). Just stating that I don't like it and
> probably won't offer real support, not blocking it.
> 
> wrt merging eclasses, could add that I wasn't really against the
> support for this being in linux-mod-r1 directly except for the part
> where it did not work when not using modlist being confusing, in the
> end I'd probably just have asked for Nowa to add themselves as
> maintainer.

(by the modlist bit, by that I meant initially -- I know dkms support
been added to emake-type ebuilds too now)

> On a related note about modlist, I've been semi-regretting keeping that
> modlist-type idea from the original linux-mod eclass and felt that a
> simple emake wrapper (incl. modules args) for all packages "might" have
> been better and easier to use for ebuilds and not miss modules on bump
> and had been pondering "potential" deprecation in the future (not that
> I had really explored that idea yet, would need to check packages).
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 4034 bytes --]

On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
> > Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
> > 
> > > I had really hoped to receive more comments on my earlier RFC. [...]
> > > 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).
> > 
> > So because I carried over my own already "works for me" kernel maintenance 
> > scripts from Mandrake when I switched in 2004 and have continued 
> > maintaining and using them over the decades since, I normally try to stay 
> > out of Gentoo kernel packaging discussion. But given both the above 
> > explicit invitation and that as I've read the thread a thought occurred to 
> > me...
> > 
> > First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> > general it should be reasonably supported in Gentoo unless it simply 
> > doesn't make sense (note that "doesn't make sense" can also include the 
> > case of simply no one stepping up to do it, not the case here).
> > 
> > But, the thought that occurred to me reading the thread, was that there 
> > are obvious parallels between this and another very significant and 
> > controversial now "cross distro standard solution" (which I guess I don't 
> > need to name explicitly).
> > 
> > As there, I believe "the Gentoo approach" should (again assuming developer 
> > willingness to do the work, seemingly the case here) make it available as 
> > an additional integrated *option*, while keeping the current Gentoo option 
> > as well.
> > 
> > So I support DKMS integration /as/ /an/ /option/.
> 
> If anything, if go forward with this, I'd rather that it be with the
> plan to (eventually) either make it the default after enough testing
> and then later drop support for the old way entirely (then merge the
> eclasses), or revert if we think it's no good.
> 
> One of the thing I did not like here is the idea to gain more ways
> to do the same thing that need to be tested to ensure some quality.
> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
> some path or something else and I don't test it on bump, then I push
> a broken package for all dkms users until someone reports it. Would
> even need to boot with it to be sure.
> 
> It's nice to have choices in general, but still need to draw some
> lines to keep things maintainable.
> 
> And if picking, in the end do we pick an option that requires to
> install sources and (imo) adds very little, or let the PM (that has
> access to sources unlike binary distros) handle it (with full control
> for handling issues) just like for dist kernels and improve on that
> as needed?
> 
> Either way, as I said initially, I won't revert if this gets merged
> (even if optional forever). Just stating that I don't like it and
> probably won't offer real support, not blocking it.
> 
> wrt merging eclasses, could add that I wasn't really against the
> support for this being in linux-mod-r1 directly except for the part
> where it did not work when not using modlist being confusing, in the
> end I'd probably just have asked for Nowa to add themselves as
> maintainer.
> 
> On a related note about modlist, I've been semi-regretting keeping that
> modlist-type idea from the original linux-mod eclass and felt that a
> simple emake wrapper (incl. modules args) for all packages "might" have
> been better and easier to use for ebuilds and not miss modules on bump
> and had been pondering "potential" deprecation in the future (not that
> I had really explored that idea yet, would need to check packages).

(this was in my notes of things to consider for EAPI 9, but likely won't
try if there is another eclass built upon linux-mod-r1 that I need to
not break)
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

On 19/03/2025 02:07, Ionen Wolkens wrote:
> On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
>> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
>>> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>>>
>>>> I had really hoped to receive more comments on my earlier RFC. [...]
>>>> 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).
>>>
>>> So because I carried over my own already "works for me" kernel maintenance
>>> scripts from Mandrake when I switched in 2004 and have continued
>>> maintaining and using them over the decades since, I normally try to stay
>>> out of Gentoo kernel packaging discussion. But given both the above
>>> explicit invitation and that as I've read the thread a thought occurred to
>>> me...
>>>
>>> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in
>>> general it should be reasonably supported in Gentoo unless it simply
>>> doesn't make sense (note that "doesn't make sense" can also include the
>>> case of simply no one stepping up to do it, not the case here).
>>>
>>> But, the thought that occurred to me reading the thread, was that there
>>> are obvious parallels between this and another very significant and
>>> controversial now "cross distro standard solution" (which I guess I don't
>>> need to name explicitly).
>>>
>>> As there, I believe "the Gentoo approach" should (again assuming developer
>>> willingness to do the work, seemingly the case here) make it available as
>>> an additional integrated *option*, while keeping the current Gentoo option
>>> as well.
>>>
>>> So I support DKMS integration /as/ /an/ /option/.
>>
>> If anything, if go forward with this, I'd rather that it be with the
>> plan to (eventually) either make it the default after enough testing
>> and then later drop support for the old way entirely (then merge the
>> eclasses), or revert if we think it's no good.

As I have already stated elsewhere, DKMS can do things that we cannot 
achieve with the package manager, and the package manager can do things 
that we cannot achieve with DKMS. Each pathway has its use cases. And 
for that reason DKMS is not a replacement for the package manager. Nor 
can I think of a possible future package manager based solution that can 
fully replace what DKMS does (though who knows, maybe someone will prove 
me wrong in 20 years)

This dual-approach is not controversial either, other distributions 
often offer a "normal" package as well as a DKMS package. Now since we 
have USE flags we do not have to make two separate packages, but 
nonetheless the core of letting the user choose to use DKMS or not 
remains the same.

>> One of the thing I did not like here is the idea to gain more ways
>> to do the same thing that need to be tested to ensure some quality.
>> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
>> some path or something else and I don't test it on bump, then I push
>> a broken package for all dkms users until someone reports it. Would
>> even need to boot with it to be sure.

I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms, 
especially if the ebuild does not use a modlist and therefore the 
dkms.conf is not constructed fully automatically. Though I do not see 
why this would require actually rebooting the system for both cases. 
DKMS either builds and installs the module successfully in postinst or 
it does not. And regardless of who did the module installing, it either 
loads successfully or it does not. Note that we are intentionally using 
the exact same commands to actually build the module in DKMS.

I'll also note again that Nvidia is one of the upstreams that supports 
DKMS, in contrast to our own linux-mod-r1 solution in portage which I 
don't think they care about at all. I'd therefore say that it is far 
more likely for Nvidia to change something that breaks the existing 
non-dkms pathway in the ebuild, then it is for them to break the dkms 
pathway that lots of other distributions rely on.

>> It's nice to have choices in general, but still need to draw some
>> lines to keep things maintainable.

This maintainability argument would be a lot stronger if I was 
reinventing the wheel and proposing some custom Gentoo specific solution 
to the problem at hand. Note though that this is not what I am doing (in 
fact one could even turn that around and say that this is what you are 
doing). You are of course right that more options means more things to 
test. But really, it's not a lot of work, I know because I did the work 
for almost all of the kernel module ebuilds we have in ::gentoo and was 
finished in half a day. The bulk of the work was designing and writing 
the eclass and figuring out all the different cases that should be 
supported, that part is done now.

>> And if picking, in the end do we pick an option that requires to
>> install sources and (imo) adds very little, or let the PM (that has
>> access to sources unlike binary distros) handle it (with full control
>> for handling issues) just like for dist kernels and improve on that
>> as needed?
>>
>> Either way, as I said initially, I won't revert if this gets merged
>> (even if optional forever). Just stating that I don't like it and
>> probably won't offer real support, not blocking it.
>>
>> wrt merging eclasses, could add that I wasn't really against the
>> support for this being in linux-mod-r1 directly except for the part
>> where it did not work when not using modlist being confusing, in the
>> end I'd probably just have asked for Nowa to add themselves as
>> maintainer.

The main reason this is in a separate eclass is because we need a 
pkg_prerm for dkms that linux-mod-r1 does not have. And as you pointed 
out earlier, exporting an extra phase function in an established eclass 
is not a good idea.

>> On a related note about modlist, I've been semi-regretting keeping that
>> modlist-type idea from the original linux-mod eclass and felt that a
>> simple emake wrapper (incl. modules args) for all packages "might" have
>> been better and easier to use for ebuilds and not miss modules on bump
>> and had been pondering "potential" deprecation in the future (not that
>> I had really explored that idea yet, would need to check packages).
> 
> (this was in my notes of things to consider for EAPI 9, but likely won't
> try if there is another eclass built upon linux-mod-r1 that I need to
> not break)

Note that none of this hard requires the modlist. The requirement is 
that we have one or more dkms.conf files. These may be provided by 
upstream (as is the case for nvidia-drivers), or generated by some build 
system script (as is the case for zfs-kmod), or included in the 
FILESDIR, or they can be generated by the eclass from the modlist.

This auto-generation option is just for convenience. The modlist already 
contains all the information we need to define the dkms.conf, so all we 
have to do is make the translation. Doing so makes it very easy for the 
package maintainer to add dkms compatibility without actually writing a 
custom dkms.conf.

If you wish to drop the modlist method from linux-mod-r1 then you can 
still do so. It just requires that when upgrading from EAPI 8 to 9 we 
also port the ebuild to so other method of providing the dkms.conf (for 
example putting a stub dkms.conf in FILESDIR, sed'ing in the PV, and 
then putting it in the proper place). I might then want to adjust the 
src_compile phase of the eclass a bit when bumping it to EAPI 9, but 
again these are all easily solvable problems, and they are also 
hypothetical problems.

In the end this eclass does not really rely on the specifics of 
linux-mod-r1 more then a consumer ebuild does. We rely on linux-mod-r1 
setting the MODULES_MAKEARGS, we rely on linux-mod-r1 to process the 
modlist and set the default values there (I split this into a separate 
function to avoid code duplication), and we rely on the 
modules_process_dracut.conf.d function (again, just to avoid code 
duplication). And that's it. Now I could drop the linux-mod-r1 commits 
that split out this processing of the modlist and make the 
modules_process_dracut.conf.d function public. But we gain nothing from 
this since the ebuilds already rely on linux-mod-r1 doing what it does 
in this area in exactly the same way that the eclass does, it only 
results in some code duplication.

Best regards,
Nowa

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 9631 bytes --]

On Wed, Mar 19, 2025 at 08:57:38AM +0100, Nowa Ammerlaan wrote:
> On 19/03/2025 02:07, Ionen Wolkens wrote:
> > On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
> >> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
> >>> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
> >>>
> >>>> I had really hoped to receive more comments on my earlier RFC. [...]
> >>>> 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).
> >>>
> >>> So because I carried over my own already "works for me" kernel maintenance
> >>> scripts from Mandrake when I switched in 2004 and have continued
> >>> maintaining and using them over the decades since, I normally try to stay
> >>> out of Gentoo kernel packaging discussion. But given both the above
> >>> explicit invitation and that as I've read the thread a thought occurred to
> >>> me...
> >>>
> >>> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in
> >>> general it should be reasonably supported in Gentoo unless it simply
> >>> doesn't make sense (note that "doesn't make sense" can also include the
> >>> case of simply no one stepping up to do it, not the case here).
> >>>
> >>> But, the thought that occurred to me reading the thread, was that there
> >>> are obvious parallels between this and another very significant and
> >>> controversial now "cross distro standard solution" (which I guess I don't
> >>> need to name explicitly).
> >>>
> >>> As there, I believe "the Gentoo approach" should (again assuming developer
> >>> willingness to do the work, seemingly the case here) make it available as
> >>> an additional integrated *option*, while keeping the current Gentoo option
> >>> as well.
> >>>
> >>> So I support DKMS integration /as/ /an/ /option/.
> >>
> >> If anything, if go forward with this, I'd rather that it be with the
> >> plan to (eventually) either make it the default after enough testing
> >> and then later drop support for the old way entirely (then merge the
> >> eclasses), or revert if we think it's no good.
> 
> As I have already stated elsewhere, DKMS can do things that we cannot 
> achieve with the package manager, and the package manager can do things 
> that we cannot achieve with DKMS. Each pathway has its use cases. And 
> for that reason DKMS is not a replacement for the package manager. Nor 
> can I think of a possible future package manager based solution that can 
> fully replace what DKMS does (though who knows, maybe someone will prove 
> me wrong in 20 years)
> 
> This dual-approach is not controversial either, other distributions 
> often offer a "normal" package as well as a DKMS package. Now since we 
> have USE flags we do not have to make two separate packages, but 
> nonetheless the core of letting the user choose to use DKMS or not 
> remains the same.
> 
> >> One of the thing I did not like here is the idea to gain more ways
> >> to do the same thing that need to be tested to ensure some quality.
> >> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
> >> some path or something else and I don't test it on bump, then I push
> >> a broken package for all dkms users until someone reports it. Would
> >> even need to boot with it to be sure.
> 
> I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms, 
> especially if the ebuild does not use a modlist and therefore the 
> dkms.conf is not constructed fully automatically. Though I do not see 
> why this would require actually rebooting the system for both cases. 
> DKMS either builds and installs the module successfully in postinst or 
> it does not. And regardless of who did the module installing, it either 
> loads successfully or it does not. Note that we are intentionally using 
> the exact same commands to actually build the module in DKMS.
> 
> I'll also note again that Nvidia is one of the upstreams that supports 
> DKMS, in contrast to our own linux-mod-r1 solution in portage which I 
> don't think they care about at all. I'd therefore say that it is far 
> more likely for Nvidia to change something that breaks the existing 
> non-dkms pathway in the ebuild, then it is for them to break the dkms 
> pathway that lots of other distributions rely on.
> 
> >> It's nice to have choices in general, but still need to draw some
> >> lines to keep things maintainable.
> 
> This maintainability argument would be a lot stronger if I was 
> reinventing the wheel and proposing some custom Gentoo specific solution 
> to the problem at hand. Note though that this is not what I am doing (in 
> fact one could even turn that around and say that this is what you are 
> doing). You are of course right that more options means more things to 
> test. But really, it's not a lot of work, I know because I did the work 
> for almost all of the kernel module ebuilds we have in ::gentoo and was 
> finished in half a day. The bulk of the work was designing and writing 
> the eclass and figuring out all the different cases that should be 
> supported, that part is done now.
> 
> >> And if picking, in the end do we pick an option that requires to
> >> install sources and (imo) adds very little, or let the PM (that has
> >> access to sources unlike binary distros) handle it (with full control
> >> for handling issues) just like for dist kernels and improve on that
> >> as needed?
> >>
> >> Either way, as I said initially, I won't revert if this gets merged
> >> (even if optional forever). Just stating that I don't like it and
> >> probably won't offer real support, not blocking it.
> >>
> >> wrt merging eclasses, could add that I wasn't really against the
> >> support for this being in linux-mod-r1 directly except for the part
> >> where it did not work when not using modlist being confusing, in the
> >> end I'd probably just have asked for Nowa to add themselves as
> >> maintainer.
> 
> The main reason this is in a separate eclass is because we need a 
> pkg_prerm for dkms that linux-mod-r1 does not have. And as you pointed 
> out earlier, exporting an extra phase function in an established eclass 
> is not a good idea.

Yes, but it could've either have become a linux-mod-r2 (and deprecate
-r1 eventually) or done on EAPI bump in the future.

I don't really see why any ebuilds should inherit linux-mod-r1 right
now when they'll just be the odd one out if they don't support dkms.
May as well merge it into dkms.eclass and get rid of it after consumers
are gone.

On that note, please just take over linux-mod-r1 maintenance if merge
this so that I won't have to care anymore.

> 
> >> On a related note about modlist, I've been semi-regretting keeping that
> >> modlist-type idea from the original linux-mod eclass and felt that a
> >> simple emake wrapper (incl. modules args) for all packages "might" have
> >> been better and easier to use for ebuilds and not miss modules on bump
> >> and had been pondering "potential" deprecation in the future (not that
> >> I had really explored that idea yet, would need to check packages).
> > 
> > (this was in my notes of things to consider for EAPI 9, but likely won't
> > try if there is another eclass built upon linux-mod-r1 that I need to
> > not break)
> 
> Note that none of this hard requires the modlist. The requirement is 
> that we have one or more dkms.conf files. These may be provided by 
> upstream (as is the case for nvidia-drivers), or generated by some build 
> system script (as is the case for zfs-kmod), or included in the 
> FILESDIR, or they can be generated by the eclass from the modlist.
> 
> This auto-generation option is just for convenience. The modlist already 
> contains all the information we need to define the dkms.conf, so all we 
> have to do is make the translation. Doing so makes it very easy for the 
> package maintainer to add dkms compatibility without actually writing a 
> custom dkms.conf.
> 
> If you wish to drop the modlist method from linux-mod-r1 then you can 
> still do so. It just requires that when upgrading from EAPI 8 to 9 we 
> also port the ebuild to so other method of providing the dkms.conf (for 
> example putting a stub dkms.conf in FILESDIR, sed'ing in the PV, and 
> then putting it in the proper place). I might then want to adjust the 
> src_compile phase of the eclass a bit when bumping it to EAPI 9, but 
> again these are all easily solvable problems, and they are also 
> hypothetical problems.
> 
> In the end this eclass does not really rely on the specifics of 
> linux-mod-r1 more then a consumer ebuild does. We rely on linux-mod-r1 
> setting the MODULES_MAKEARGS, we rely on linux-mod-r1 to process the 
> modlist and set the default values there (I split this into a separate 
> function to avoid code duplication), and we rely on the 
> modules_process_dracut.conf.d function (again, just to avoid code 
> duplication). And that's it. Now I could drop the linux-mod-r1 commits 
> that split out this processing of the modlist and make the 
> modules_process_dracut.conf.d function public. But we gain nothing from 
> this since the ebuilds already rely on linux-mod-r1 doing what it does 
> in this area in exactly the same way that the eclass does, it only 
> results in some code duplication.
> 
> Best regards,
> Nowa
> 

-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

On 19/03/2025 09:48, Ionen Wolkens wrote:
> On Wed, Mar 19, 2025 at 08:57:38AM +0100, Nowa Ammerlaan wrote:
>> On 19/03/2025 02:07, Ionen Wolkens wrote:
>>> On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
>>>> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
>>>>> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>>>>>
>>>>>> I had really hoped to receive more comments on my earlier RFC. [...]
>>>>>> 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).
>>>>>
>>>>> So because I carried over my own already "works for me" kernel maintenance
>>>>> scripts from Mandrake when I switched in 2004 and have continued
>>>>> maintaining and using them over the decades since, I normally try to stay
>>>>> out of Gentoo kernel packaging discussion. But given both the above
>>>>> explicit invitation and that as I've read the thread a thought occurred to
>>>>> me...
>>>>>
>>>>> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in
>>>>> general it should be reasonably supported in Gentoo unless it simply
>>>>> doesn't make sense (note that "doesn't make sense" can also include the
>>>>> case of simply no one stepping up to do it, not the case here).
>>>>>
>>>>> But, the thought that occurred to me reading the thread, was that there
>>>>> are obvious parallels between this and another very significant and
>>>>> controversial now "cross distro standard solution" (which I guess I don't
>>>>> need to name explicitly).
>>>>>
>>>>> As there, I believe "the Gentoo approach" should (again assuming developer
>>>>> willingness to do the work, seemingly the case here) make it available as
>>>>> an additional integrated *option*, while keeping the current Gentoo option
>>>>> as well.
>>>>>
>>>>> So I support DKMS integration /as/ /an/ /option/.
>>>>
>>>> If anything, if go forward with this, I'd rather that it be with the
>>>> plan to (eventually) either make it the default after enough testing
>>>> and then later drop support for the old way entirely (then merge the
>>>> eclasses), or revert if we think it's no good.
>>
>> As I have already stated elsewhere, DKMS can do things that we cannot
>> achieve with the package manager, and the package manager can do things
>> that we cannot achieve with DKMS. Each pathway has its use cases. And
>> for that reason DKMS is not a replacement for the package manager. Nor
>> can I think of a possible future package manager based solution that can
>> fully replace what DKMS does (though who knows, maybe someone will prove
>> me wrong in 20 years)
>>
>> This dual-approach is not controversial either, other distributions
>> often offer a "normal" package as well as a DKMS package. Now since we
>> have USE flags we do not have to make two separate packages, but
>> nonetheless the core of letting the user choose to use DKMS or not
>> remains the same.
>>
>>>> One of the thing I did not like here is the idea to gain more ways
>>>> to do the same thing that need to be tested to ensure some quality.
>>>> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
>>>> some path or something else and I don't test it on bump, then I push
>>>> a broken package for all dkms users until someone reports it. Would
>>>> even need to boot with it to be sure.
>>
>> I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms,
>> especially if the ebuild does not use a modlist and therefore the
>> dkms.conf is not constructed fully automatically. Though I do not see
>> why this would require actually rebooting the system for both cases.
>> DKMS either builds and installs the module successfully in postinst or
>> it does not. And regardless of who did the module installing, it either
>> loads successfully or it does not. Note that we are intentionally using
>> the exact same commands to actually build the module in DKMS.
>>
>> I'll also note again that Nvidia is one of the upstreams that supports
>> DKMS, in contrast to our own linux-mod-r1 solution in portage which I
>> don't think they care about at all. I'd therefore say that it is far
>> more likely for Nvidia to change something that breaks the existing
>> non-dkms pathway in the ebuild, then it is for them to break the dkms
>> pathway that lots of other distributions rely on.
>>
>>>> It's nice to have choices in general, but still need to draw some
>>>> lines to keep things maintainable.
>>
>> This maintainability argument would be a lot stronger if I was
>> reinventing the wheel and proposing some custom Gentoo specific solution
>> to the problem at hand. Note though that this is not what I am doing (in
>> fact one could even turn that around and say that this is what you are
>> doing). You are of course right that more options means more things to
>> test. But really, it's not a lot of work, I know because I did the work
>> for almost all of the kernel module ebuilds we have in ::gentoo and was
>> finished in half a day. The bulk of the work was designing and writing
>> the eclass and figuring out all the different cases that should be
>> supported, that part is done now.
>>
>>>> And if picking, in the end do we pick an option that requires to
>>>> install sources and (imo) adds very little, or let the PM (that has
>>>> access to sources unlike binary distros) handle it (with full control
>>>> for handling issues) just like for dist kernels and improve on that
>>>> as needed?
>>>>
>>>> Either way, as I said initially, I won't revert if this gets merged
>>>> (even if optional forever). Just stating that I don't like it and
>>>> probably won't offer real support, not blocking it.
>>>>
>>>> wrt merging eclasses, could add that I wasn't really against the
>>>> support for this being in linux-mod-r1 directly except for the part
>>>> where it did not work when not using modlist being confusing, in the
>>>> end I'd probably just have asked for Nowa to add themselves as
>>>> maintainer.
>>
>> The main reason this is in a separate eclass is because we need a
>> pkg_prerm for dkms that linux-mod-r1 does not have. And as you pointed
>> out earlier, exporting an extra phase function in an established eclass
>> is not a good idea.
> 
> Yes, but it could've either have become a linux-mod-r2 (and deprecate
> -r1 eventually) or done on EAPI bump in the future.
> 
> I don't really see why any ebuilds should inherit linux-mod-r1 right
> now when they'll just be the odd one out if they don't support dkms.
> May as well merge it into dkms.eclass and get rid of it after consumers
> are gone.

We can still do that (i.e. merge it all into one eclass named 
linux-mod-r2 instead of inheriting linux-mod-r1), but from our earlier 
discussion it was my impression that this is not what you wanted. We 
could even add dkms as a separate eclass now, and then merge it back 
into a possible linux-mod-r2 in the future (if/when there are other 
things we want to do that warrant a revision bump such as the 
multi-build approach that you suggested before).

> On that note, please just take over linux-mod-r1 maintenance if merge
> this so that I won't have to care anymore.

Ionen, I'm getting the impression that you're taking what I said a bit 
personally. It is not my intention to attack you or your work, on the 
contrary. I may argue (too) passionately, but that is because I believe 
I am right and I am still trying to convince you of this because I'd 
rather not merge this in if you are strongly opposed. Now I am happy to 
co-maintain linux-mod-r1 (or -r2 if that is the route we want to take), 
as you know I've already submitted a number of patches for it before 
because it intersects closely with the dist-kernel eclasses. That being 
said, I do not wish to usurp your position here.

Best regards,
Nowa

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Sam James]

Nowa Ammerlaan <nowa@gentoo.org> writes:

> On 19/03/2025 02:07, Ionen Wolkens wrote:
>> On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
>>> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
>>>> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>>>>
>>>>> I had really hoped to receive more comments on my earlier RFC. [...]
>>>>> 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).
>>>>
>>>> So because I carried over my own already "works for me" kernel maintenance
>>>> scripts from Mandrake when I switched in 2004 and have continued
>>>> maintaining and using them over the decades since, I normally try to stay
>>>> out of Gentoo kernel packaging discussion. But given both the above
>>>> explicit invitation and that as I've read the thread a thought occurred to
>>>> me...
>>>>
>>>> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in
>>>> general it should be reasonably supported in Gentoo unless it simply
>>>> doesn't make sense (note that "doesn't make sense" can also include the
>>>> case of simply no one stepping up to do it, not the case here).
>>>>
>>>> But, the thought that occurred to me reading the thread, was that there
>>>> are obvious parallels between this and another very significant and
>>>> controversial now "cross distro standard solution" (which I guess I don't
>>>> need to name explicitly).
>>>>
>>>> As there, I believe "the Gentoo approach" should (again assuming developer
>>>> willingness to do the work, seemingly the case here) make it available as
>>>> an additional integrated *option*, while keeping the current Gentoo option
>>>> as well.
>>>>
>>>> So I support DKMS integration /as/ /an/ /option/.
>>>
>>> If anything, if go forward with this, I'd rather that it be with the
>>> plan to (eventually) either make it the default after enough testing
>>> and then later drop support for the old way entirely (then merge the
>>> eclasses), or revert if we think it's no good.
>
> As I have already stated elsewhere, DKMS can do things that we cannot
> achieve with the package manager, and the package manager can do
> things that we cannot achieve with DKMS. Each pathway has its use
> cases. And for that reason DKMS is not a replacement for the package
> manager. Nor can I think of a possible future package manager based
> solution that can fully replace what DKMS does (though who knows,
> maybe someone will prove me wrong in 20 years)
>
> This dual-approach is not controversial either, other distributions
> often offer a "normal" package as well as a DKMS package. Now since we
> have USE flags we do not have to make two separate packages, but
> nonetheless the core of letting the user choose to use DKMS or not
> remains the same.
>
>>> One of the thing I did not like here is the idea to gain more ways
>>> to do the same thing that need to be tested to ensure some quality.
>>> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
>>> some path or something else and I don't test it on bump, then I push
>>> a broken package for all dkms users until someone reports it. Would
>>> even need to boot with it to be sure.
>
> I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms,
> especially if the ebuild does not use a modlist and therefore the
> dkms.conf is not constructed fully automatically. Though I do not see
> why this would require actually rebooting the system for both
> cases. DKMS either builds and installs the module successfully in
> postinst or it does not. And regardless of who did the module
> installing, it either loads successfully or it does not. Note that we
> are intentionally using the exact same commands to actually build the
> module in DKMS.

If we're doing it orphaned, it should be done as hooks instead rather
than with any integration in the ebuild, though. postinst / orphaned
files are broadly a hack. Orphaned files break a bunch of invariants
including Just Working for binpkgs properly.

I also agree with Ionen that this is important enough that I'd want this
to be the primary path (and fully tested & supported), not done at
all. But wanting to support *both* long-time makes me uneasy.

> [...]
>
>>> It's nice to have choices in general, but still need to draw some
>>> lines to keep things maintainable.
>
> This maintainability argument would be a lot stronger if I was
> reinventing the wheel and proposing some custom Gentoo specific
> solution to the problem at hand. Note though that this is not what I
> am doing (in fact one could even turn that around and say that this is
> what you are doing). You are of course right that more options means
> more things to test. But really, it's not a lot of work, I know
> because I did the work for almost all of the kernel module ebuilds we
> have in ::gentoo and was finished in half a day. The bulk of the work
> was designing and writing the eclass and figuring out all the
> different cases that should be supported, that part is done now.
>

But none of this does feel particularly native to Gentoo. Most of the
Linux world is of binary distros, so while it may not be NIH, it
somewhat is NIH wrt source distros (or can feel like that).

In the same way, Eli and I have some different opinions on splitpkgs --
he's sort of convinced me that there's some utility in them, but they're
in no way *as useful* as they are on primarily-binary distributions.

But I don't consider myself an expert on kernel modules either, just the
fact that Ionen shares my unease (or I share his) makes me feel like
mine isn't unwarranted.

> [...]

thanks,
sam

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 3530 bytes --]

On 3/19/25 6:10 PM, Sam James wrote:
> If we're doing it orphaned, it should be done as hooks instead rather
> than with any integration in the ebuild, though. postinst / orphaned
> files are broadly a hack. Orphaned files break a bunch of invariants
> including Just Working for binpkgs properly.
> 
> I also agree with Ionen that this is important enough that I'd want this
> to be the primary path (and fully tested & supported), not done at
> all. But wanting to support *both* long-time makes me uneasy.


Shower thought, but if interested in guaranteeing a single tested path,
it is possible to unconditionally prep the source tree for dkms, then
have USE=dkms decide whether to:

- install the sources to /usr/src

- build the module in the ebuild and install it in src_install, via
  running the `dkms build` command


This would mean making dkms a dependency as such:

BDEPEND="
    !dkms? ( sys-kernel/dkms )
"
RDEPEND="
    dkms? ( sys-kernel/dkms )
"

I suppose that not everyone will necessarily like this. But it should be
technically feasible, at least.


>> [...]
>>
>>>> It's nice to have choices in general, but still need to draw some
>>>> lines to keep things maintainable.
>>
>> This maintainability argument would be a lot stronger if I was
>> reinventing the wheel and proposing some custom Gentoo specific
>> solution to the problem at hand. Note though that this is not what I
>> am doing (in fact one could even turn that around and say that this is
>> what you are doing). You are of course right that more options means
>> more things to test. But really, it's not a lot of work, I know
>> because I did the work for almost all of the kernel module ebuilds we
>> have in ::gentoo and was finished in half a day. The bulk of the work
>> was designing and writing the eclass and figuring out all the
>> different cases that should be supported, that part is done now.
>>
> 
> But none of this does feel particularly native to Gentoo. Most of the
> Linux world is of binary distros, so while it may not be NIH, it
> somewhat is NIH wrt source distros (or can feel like that).
> 
> In the same way, Eli and I have some different opinions on splitpkgs --
> he's sort of convinced me that there's some utility in them, but they're
> in no way *as useful* as they are on primarily-binary distributions.


Couldn't you say the same thing about gentoo-sources? Like dkms, this
entails installing source code which users will then compile and install
outside of an ebuild.

In fact this is one of the biggest reasons I think supporting dkms on
Gentoo is important, because I can't see how one could *build* a kernel
module in src_install and install it as part of CONTENTS, when you don't
actually know what kernels are installed.

I mean, sure, you could treat emerge as a hook program to iteratively
build orphaned modules for orphaned kernels via manual non-portage steps
to bamboozle emerge into thinking that's "the kernel" to use. Many
things are possible, given sufficient determination. But the discussion
is about what feels native and clean and "not a hack".

And what seems "not a hack" to me is that if you install kernel sources,
you should be able to install module sources too.


> But I don't consider myself an expert on kernel modules either, just the
> fact that Ionen shares my unease (or I share his) makes me feel like
> mine isn't unwarranted.
> 
>> [...]
> 
> thanks,
> sam
> 


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

On 19/03/2025 23:37, Eli Schwartz wrote:
> On 3/19/25 6:10 PM, Sam James wrote:
>> If we're doing it orphaned, it should be done as hooks instead rather
>> than with any integration in the ebuild, though. postinst / orphaned
>> files are broadly a hack. Orphaned files break a bunch of invariants
>> including Just Working for binpkgs properly.
>>
>> I also agree with Ionen that this is important enough that I'd want this
>> to be the primary path (and fully tested & supported), not done at
>> all. But wanting to support *both* long-time makes me uneasy.
> 
> 
> Shower thought, but if interested in guaranteeing a single tested path,
> it is possible to unconditionally prep the source tree for dkms, then
> have USE=dkms decide whether to:
> 
> - install the sources to /usr/src
> 
> - build the module in the ebuild and install it in src_install, via
>    running the `dkms build` command

Making the prepping (i.e. the creation/seding/moving of the dkms.conf 
files) unconditional is definitely doable.

I'm not sure about calling 'dkms build' in src_install. DKMS has some 
switches to move around the location of the module and dkms tree that we 
could in theory use to have it operate on the ED instead of the EROOT. 
But it does expect some files to be already there. Though perhaps we 
could solve this with some symlinks.

That being said, this would add more complexity, and we also run into 
the problem that sys-kernel/dkms is not keyworded everywhere (yet). 
Furthermore, we still keep the dkms USE flag, so fundamentally there are 
still two paths to test.


> This would mean making dkms a dependency as such:
> 
> BDEPEND="
>      !dkms? ( sys-kernel/dkms )
> "
> RDEPEND="
>      dkms? ( sys-kernel/dkms )
> "
> 
> I suppose that not everyone will necessarily like this. But it should be
> technically feasible, at least.
> 

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Nowa Ammerlaan]

On 19/03/2025 23:10, Sam James wrote:
> Nowa Ammerlaan <nowa@gentoo.org> writes:
> 
>> On 19/03/2025 02:07, Ionen Wolkens wrote:
>>> On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
>>>> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
>>>>> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>>>>>
>>>>>> I had really hoped to receive more comments on my earlier RFC. [...]
>>>>>> 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).
>>>>>
>>>>> So because I carried over my own already "works for me" kernel maintenance
>>>>> scripts from Mandrake when I switched in 2004 and have continued
>>>>> maintaining and using them over the decades since, I normally try to stay
>>>>> out of Gentoo kernel packaging discussion. But given both the above
>>>>> explicit invitation and that as I've read the thread a thought occurred to
>>>>> me...
>>>>>
>>>>> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in
>>>>> general it should be reasonably supported in Gentoo unless it simply
>>>>> doesn't make sense (note that "doesn't make sense" can also include the
>>>>> case of simply no one stepping up to do it, not the case here).
>>>>>
>>>>> But, the thought that occurred to me reading the thread, was that there
>>>>> are obvious parallels between this and another very significant and
>>>>> controversial now "cross distro standard solution" (which I guess I don't
>>>>> need to name explicitly).
>>>>>
>>>>> As there, I believe "the Gentoo approach" should (again assuming developer
>>>>> willingness to do the work, seemingly the case here) make it available as
>>>>> an additional integrated *option*, while keeping the current Gentoo option
>>>>> as well.
>>>>>
>>>>> So I support DKMS integration /as/ /an/ /option/.
>>>>
>>>> If anything, if go forward with this, I'd rather that it be with the
>>>> plan to (eventually) either make it the default after enough testing
>>>> and then later drop support for the old way entirely (then merge the
>>>> eclasses), or revert if we think it's no good.
>>
>> As I have already stated elsewhere, DKMS can do things that we cannot
>> achieve with the package manager, and the package manager can do
>> things that we cannot achieve with DKMS. Each pathway has its use
>> cases. And for that reason DKMS is not a replacement for the package
>> manager. Nor can I think of a possible future package manager based
>> solution that can fully replace what DKMS does (though who knows,
>> maybe someone will prove me wrong in 20 years)
>>
>> This dual-approach is not controversial either, other distributions
>> often offer a "normal" package as well as a DKMS package. Now since we
>> have USE flags we do not have to make two separate packages, but
>> nonetheless the core of letting the user choose to use DKMS or not
>> remains the same.
>>
>>>> One of the thing I did not like here is the idea to gain more ways
>>>> to do the same thing that need to be tested to ensure some quality.
>>>> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
>>>> some path or something else and I don't test it on bump, then I push
>>>> a broken package for all dkms users until someone reports it. Would
>>>> even need to boot with it to be sure.
>>
>> I'll grant that you'd indeed have to test both USE=dkms and USE=-dkms,
>> especially if the ebuild does not use a modlist and therefore the
>> dkms.conf is not constructed fully automatically. Though I do not see
>> why this would require actually rebooting the system for both
>> cases. DKMS either builds and installs the module successfully in
>> postinst or it does not. And regardless of who did the module
>> installing, it either loads successfully or it does not. Note that we
>> are intentionally using the exact same commands to actually build the
>> module in DKMS.
> 
> If we're doing it orphaned, it should be done as hooks instead rather
> than with any integration in the ebuild, though. postinst / orphaned
> files are broadly a hack. Orphaned files break a bunch of invariants
> including Just Working for binpkgs properly.

I'm sorry but this does not make any sense to me. What is orphaned here? 
The module sources are owned by the package (installed in src_install), 
the only thing that is not owned by the package is the built kernel 
module itself. And, by design, this is already effectively orphaned 
since the package manager does not remove files from /lib/modules 
anyway. I don't see how my proposal is orphaning more files.

> I also agree with Ionen that this is important enough that I'd want this
> to be the primary path (and fully tested & supported), not done at
> all. But wanting to support *both* long-time makes me uneasy.
> 
>> [...]
>>
>>>> It's nice to have choices in general, but still need to draw some
>>>> lines to keep things maintainable.
>>
>> This maintainability argument would be a lot stronger if I was
>> reinventing the wheel and proposing some custom Gentoo specific
>> solution to the problem at hand. Note though that this is not what I
>> am doing (in fact one could even turn that around and say that this is
>> what you are doing). You are of course right that more options means
>> more things to test. But really, it's not a lot of work, I know
>> because I did the work for almost all of the kernel module ebuilds we
>> have in ::gentoo and was finished in half a day. The bulk of the work
>> was designing and writing the eclass and figuring out all the
>> different cases that should be supported, that part is done now.
>>
> 
> But none of this does feel particularly native to Gentoo. Most of the
> Linux world is of binary distros, so while it may not be NIH, it
> somewhat is NIH wrt source distros (or can feel like that).

Can you explain to me what exactly about DKMS makes you feel like it is 
not for Gentoo? I do not share this feeling and I am having a hard time 
wrapping my head around it. As I already said elsewhere, binary distros 
(e.g. Arch) can and do offer *both* prebuilt packages *and* dkms source 
packages. So evidently binary distros do not have to use DKMS if they do 
not want to, though many choose to because it is convenient. This 
convenience of dynamically managing the kernel modules instead of 
statically applies to Gentoo just as much as it does to other 
distributions. It has absolutely nothing to do with the package manager 
being able to build from source itself or not.

It is inherent to the nature of the kernel modules that they will have 
to be built from source (by the user or the packager) targeting a 
specific kernel version. All I am changing here is *when* the module is 
built and installed (dynamically versus statically). And I believe this 
choice of when the module is built should be left to the user (just as 
we have gentoo-sources vs gentoo-kernel).

> In the same way, Eli and I have some different opinions on splitpkgs --
> he's sort of convinced me that there's some utility in them, but they're
> in no way *as useful* as they are on primarily-binary distributions.
> 
> But I don't consider myself an expert on kernel modules either, just the
> fact that Ionen shares my unease (or I share his) makes me feel like
> mine isn't unwarranted.
> 
>> [...]
> 
> thanks,
> sam

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

On Tue, Mar 18, 2025 at 08:34:43PM -0400, Ionen Wolkens wrote:
> On Tue, Mar 18, 2025 at 03:14:13AM -0000, Duncan wrote:
> > Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
> > 
> > > I had really hoped to receive more comments on my earlier RFC. [...]
> > > 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).
> > 
> > So because I carried over my own already "works for me" kernel maintenance 
> > scripts from Mandrake when I switched in 2004 and have continued 
> > maintaining and using them over the decades since, I normally try to stay 
> > out of Gentoo kernel packaging discussion. But given both the above 
> > explicit invitation and that as I've read the thread a thought occurred to 
> > me...
> > 
> > First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> > general it should be reasonably supported in Gentoo unless it simply 
> > doesn't make sense (note that "doesn't make sense" can also include the 
> > case of simply no one stepping up to do it, not the case here).
> > 
> > But, the thought that occurred to me reading the thread, was that there 
> > are obvious parallels between this and another very significant and 
> > controversial now "cross distro standard solution" (which I guess I don't 
> > need to name explicitly).
> > 
> > As there, I believe "the Gentoo approach" should (again assuming developer 
> > willingness to do the work, seemingly the case here) make it available as 
> > an additional integrated *option*, while keeping the current Gentoo option 
> > as well.
> > 
> > So I support DKMS integration /as/ /an/ /option/.
> 
> If anything, if go forward with this, I'd rather that it be with the
> plan to (eventually) either make it the default after enough testing
> and then later drop support for the old way entirely (then merge the
> eclasses), or revert if we think it's no good.
> 
> One of the thing I did not like here is the idea to gain more ways
> to do the same thing that need to be tested to ensure some quality.
> Can't ignore it and leave it all to Nowa given if e.g. nvidia changes
> some path or something else and I don't test it on bump, then I push
> a broken package for all dkms users until someone reports it. Would
> even need to boot with it to be sure.

And looking at ebuilds in the PR, fair amount of ebuilds now have
extra `use dkms` logic to consider and not fully transparently handled
by the eclass. I'd rather see this dropped in the future to support
only one way whichever it is.

> 
> It's nice to have choices in general, but still need to draw some
> lines to keep things maintainable.
> 
> And if picking, in the end do we pick an option that requires to
> install sources and (imo) adds very little, or let the PM (that has
> access to sources unlike binary distros) handle it (with full control
> for handling issues) just like for dist kernels and improve on that
> as needed?

...not that I feel the dkms way is the right one (for us).

> 
> Either way, as I said initially, I won't revert if this gets merged
> (even if optional forever). Just stating that I don't like it and
> probably won't offer real support, not blocking it.
> 
> wrt merging eclasses, could add that I wasn't really against the
> support for this being in linux-mod-r1 directly except for the part
> where it did not work when not using modlist being confusing, in the
> end I'd probably just have asked for Nowa to add themselves as
> maintainer.
> 
> On a related note about modlist, I've been semi-regretting keeping that
> modlist-type idea from the original linux-mod eclass and felt that a
> simple emake wrapper (incl. modules args) for all packages "might" have
> been better and easier to use for ebuilds and not miss modules on bump
> and had been pondering "potential" deprecation in the future (not that
> I had really explored that idea yet, would need to check packages).
-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Re: [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Sam James]

Duncan <1i5t5.duncan@cox.net> writes:

> Nowa Ammerlaan posted on Mon, 17 Mar 2025 11:11:06 +0100 as excerpted:
>
>> I had really hoped to receive more comments on my earlier RFC. [...]
>> 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).
>
> So because I carried over my own already "works for me" kernel maintenance 
> scripts from Mandrake when I switched in 2004 and have continued 
> maintaining and using them over the decades since, I normally try to stay 
> out of Gentoo kernel packaging discussion. But given both the above 
> explicit invitation and that as I've read the thread a thought occurred to 
> me...
>
> First, DKMS /is/ a cross-distro standard solution.  As such, I believe in 
> general it should be reasonably supported in Gentoo unless it simply 
> doesn't make sense (note that "doesn't make sense" can also include the 
> case of simply no one stepping up to do it, not the case here).
>
> But, the thought that occurred to me reading the thread, was that there 
> are obvious parallels between this and another very significant and 
> controversial now "cross distro standard solution" (which I guess I don't 
> need to name explicitly).
>
> As there, I believe "the Gentoo approach" should (again assuming developer 
> willingness to do the work, seemingly the case here) make it available as 
> an additional integrated *option*, while keeping the current Gentoo option 
> as well.
>
> So I support DKMS integration /as/ /an/ /option/.

I do generally appreciate your input, but I'll note that this email
boils down to "choice is good" (even though you're seemingly not going
to use this at all).

This is somewhat of a meme and doesn't really make sense in isolation,
given maintainability and clear documentation is always something we
have to weigh up more options with.

Re: [gentoo-dev] [PATCH 4/5] linux-mod-r1.eclass: make modules_process_dracut.conf.d public

[Eli Schwartz]

[-- Attachment #1.1: Type: text/plain, Size: 7587 bytes --]

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 choice.

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.
> 
> 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).
> 
> 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.


-- 
Eli Schwartz

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[gentoo-dev] [PATCH 5/5] dkms.eclass: introduce new eclass

[Nowa Ammerlaan]

Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
---
 eclass/dkms.eclass | 545 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 545 insertions(+)
 create mode 100644 eclass/dkms.eclass

diff --git a/eclass/dkms.eclass b/eclass/dkms.eclass
new file mode 100644
index 000000000000..c445b95721c3
--- /dev/null
+++ b/eclass/dkms.eclass
@@ -0,0 +1,545 @@
+# Copyright 2025 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: dkms.eclass
+# @MAINTAINER:
+# Nowa Ammerlaan <nowa@gentoo.org>
+# @AUTHOR:
+# Author: Nowa Ammerlaan <nowa@gentoo.org>
+# @SUPPORTED_EAPIS: 8
+# @PROVIDES: linux-mod-r1
+# @BLURB: Helper eclass to manage DKMS modules
+# @DESCRIPTION:
+# Registers, builds and installs kernel modules using the DKMS
+# (Dynamic Kernel Module Support) system provided by sys-kernel/dkms.
+#
+# The dkms_autoconf may be used to translate the modlist and modargs
+# arrays from linux-mod-r1.eclass to a DKMS configuration file.
+#
+# If the upstream sources already contain a DKMS configuration file
+# this may be used instead of the dkms_autoconf function. In this
+# case dkms_gentoofy_conf function may be used to insert the users
+# compiler, MAKEOPTS and *FLAGS preferences into the DKMS
+# configuration file.
+#
+# The dkms_dopackage function is used to install a DKMS package, this
+# function expects to find a dkms.conf file at the path specified
+# by the argument passed to this function. If not path is specified
+# the current working directory is used.
+#
+# For convenience this eclass exports a src_compile function that runs
+# dkms_autoconf if the dkms USE flag is enabled, and if the flag is
+# disabled it runs linux-mod-r1_src_compile instead. Similarly,
+# the src_install function exported by this eclass finds any
+# dkms.conf files in the current working directory or one of its
+# subdirectories and then calls dkms_dopackage for these packages.
+# And if the dkms USE flag is disabled it runs
+# linux-mod-r1_src_install instead.
+#
+# The pkg_postinst and pkg_postrm functions then take care of
+# (de)registering, (un)building, removing, and/or adding the DKMS
+# packages. For convenience the eclass also exports a pkg_config
+# function that rebuilds and reinstalls any DKMS packages the ebuild
+# owns for the currently running kernel.
+#
+# @EXAMPLE:
+#
+# To add DKMS support to an ebuild currently using only linux-mod-r1.
+#
+# Change:
+#
+# @CODE
+# inherit linux-mod-r1
+#
+# src_compile() {
+#     local modlist=(
+#         gentoo
+#         gamepad=kernel/drivers/hid:gamepad:gamepad/obj
+#     )
+#     local modargs=( NIH_SOURCE="${KV_OUT_DIR}" )
+#
+#     linux-mod-r1_src_compile
+# }
+# @CODE
+#
+# To:
+#
+# @CODE
+# inherit dkms
+#
+# src_compile() {
+#     local modlist=(
+#         gentoo
+#         gamepad=kernel/drivers/hid:gamepad:gamepad/obj
+#     )
+#     local modargs=( NIH_SOURCE="${KV_OUT_DIR}" )
+#
+#     dkms_src_compile
+# }
+# @CODE
+#
+# Note that due to the inherit order the src_install and pkg_postinst
+# phase functions may have to be defined explicitly.
+#
+# @EXAMPLE:
+#
+# A more complex example is the case of an ebuild that is currently
+# inheriting linux-mod-r1, but is not using any of its phase
+# functions. In this case there is usually no modlist for
+# dkms_autoconf to convert into a DKMS configuration file.
+# Instead the ebuild must utilize a dkms.conf provided by upstream
+# in the sources, or alternatively create one from scratch and
+# include it in FILESDIR.
+#
+# Tip: Check if there is a rpm/deb spec or similar script that can
+# create a dkms.conf to find a hint of what it should look like and
+# where it should be created for this particular package.
+#
+# @CODE
+# inherit dkms linux-mod-r1
+#
+# src_prepare() {
+#   default
+#   sed -e "s/@VERSION@/${PV}/" -i modules/dkms.conf || die
+# }
+#
+# src_compile() {
+#     if use dkms; then
+#         dkms_gentoofy_conf modules/dkms.conf
+#     else
+#         emake "${MODULES_MAKEARGS[@]}" modules
+#     fi
+# }
+#
+# src_install() {
+#     if use dkms; then
+#         dkms_dopackage modules
+#     else
+#         linux_domodule modules/mymodule.ko
+#         modules_post_process
+#     fi
+#     einstalldocs
+# }
+#
+# pkg_postinst() {
+#     dkms_pkg_postinst
+# }
+# @CODE
+
+case ${EAPI} in
+	8) ;;
+	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
+if [[ -z ${_DKMS_ECLASS} ]]; then
+_DKMS_ECLASS=1
+
+inherit linux-mod-r1
+
+IUSE="dkms"
+
+RDEPEND="dkms? ( sys-kernel/dkms ${BDEPEND} )"
+IDEPEND="dkms? ( sys-kernel/dkms ${BDEPEND} )"
+
+# @ECLASS_VARIABLE: DKMS_PACKAGES
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# After dkms_src_install or dkms_dopackage this array will be
+# populated with all dkms packages installed by the ebuild. The names
+# and versions of each package are separated with a ':'.
+DKMS_PACKAGES=()
+
+# @FUNCTION: dkms_gentoofy_conf
+# @USAGE: <list of files>
+# @DESCRIPTION:
+# Adds linux-mod-r1's MODULES_MAKEARGS and the ebuilds modargs to any
+# make calls in an existing dkms.conf. This function must be called
+# for every dkms.conf that will be installed to ensure that the users
+# compiler choice and flags are respected by DKMS at runtime.
+# Multiple files may be passed to this function as arguments. If no
+# arguments are given than this function runs on the dkms.conf in the
+# present working directory. Does nothing if USE=dkms is disabled.
+dkms_gentoofy_conf() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local file input=( "${@}" )
+	[[ ${#} -eq 0 ]] && input=( dkms.conf )
+
+	# This will set edkmsargs
+	dkms_sanitize_makeargs
+
+	for file in "${input[@]}"; do
+		[[ -f ${file} ]] ||
+			die "${FUNCNAME}: DKMS conf does not exist: ${file}"
+
+		sed -i "${file}" \
+			-e "/^MAKE/ s:make :make ${edkmsargs[*]} :" \
+			-e "/^MAKE/ s:make$:make ${edkmsargs[*]}:" \
+			-e "/^MAKE/ s:make\":make ${edkmsargs[*]}\":" \
+			-e "/^MAKE/ s:'make' :'make' ${edkmsargs[*]} : " \
+			-e "/^MAKE/ s:'make'$:'make' ${edkmsargs[*]}:" \
+			-e "/^MAKE/ s:'make'\":'make' ${edkmsargs[*]}\":" ||
+				die "${FUNCNAME}: failed to Gentoo'fy ${file}"
+	done
+}
+
+# @FUNCTION: dkms_sanitize_makeargs
+# @DESCRIPTION:
+# Uses linux-mod-r1's MODULES_MAKEARGS and modargs to set the
+# edkmsargs array. This array contains all variables from the two
+# input arrays except those referencing the current kernel version.
+# Quotes are added to the variables to prevent parsing problems at
+# DKMS runtime. Does nothing if USE=dkms is disabled.
+dkms_sanitize_makeargs() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local -a args=( "${MODULES_MAKEARGS[@]}" )
+	[[ ${modargs@a} == *a* ]] && args+=( "${modargs[@]}" )
+
+	edkmsargs=( ${MAKEOPTS} )
+	local arg
+	for arg in "${args[@]}"; do
+		# Replace Gentoo kernel targets with DKMS variables
+		case ${arg} in
+			*=${KV_OUT_DIR}|*=${KV_DIR})
+				edkmsargs+=( "${arg%%=*}=\${kernel_source_dir}" )
+			;;
+			${KV_OUT_DIR}|${KV_DIR})
+				edkmsargs+=( "\${kernel_source_dir}" )
+			;;
+			*=${KV_FULL})
+				edkmsargs+=( "${arg%%=*}=\${kernelver}" )
+			;;
+			${KV_FULL})
+				edkmsargs+=( "\${kernelver}" )
+			;;
+			*${KV_FULL}*|*${KV_DIR}*|*${KV_OUT_DIR}*)
+				# Skip other arguments pointing to the current target
+				continue
+			;;
+			*=*)
+				# Quote values for variables to avoid parsing problems
+				edkmsargs+=( "${arg%%=*}='${arg#*=}'" )
+			;;
+			*)
+				edkmsargs+=( "${arg}" )
+			;;
+		esac
+	done
+}
+
+# @FUNCTION: dkms_autoconf
+# @USAGE: [--no-kernelrelease|--no-autoinstall]
+# @DESCRIPTION:
+# Uses linux-mod-r1's modlist and modargs to construct a DKMS
+# configuration file. By default DKMS adds the 'KERNELRELEASE='
+# variable to all make commands. Some Makefiles will behave
+# differently when this variable is set, if this leads to problems
+# pass the --no-kernelrelease argument to this function to suppress
+# the addition of 'KERNELRELEASE=' to the calls to make at runtime.
+# By default the created DKMS configuration file will enable
+# automatic installation of all kernel modules. To disable this add
+# the --no-autoinstall argument. Does nothing if USE=dkms is disabled.
+dkms_autoconf() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local arg autoinstall=1 make_command=make
+	[[ ${#} -gt 2 ]] && die "${FUNCNAME}: too many arguments"
+	for arg in "${@}"; do
+		case ${arg} in
+			--no-kernelrelease)
+				# Per DKMS manual, quoting disables setting KERNELRELEASE
+				make_command=\'make\'
+			;;
+			--no-autoinstall)
+				autoinstall=
+			;;
+			*)
+				die "${FUNCNAME}: invalid argument ${arg}"
+			;;
+		esac
+	done
+
+	modules_process_modlist
+
+	local index mod name package dkms_config_files=()
+	for mod in "${modlist[@]}"; do
+		name=${mod%%=*}
+		mod=${mod#"${name}"}
+		IFS=: read -ra mod <<<"${mod#=}"
+
+		pushd "${mod[1]}" >/dev/null || die
+		if [[ -f dkms.conf ]]; then
+			# Find the index of an existing module, else find the
+			# first available index.
+			index=$(
+				source dkms.conf &>/dev/null ||
+					die "${FUNCNAME}: invalid dkms.conf at ${PWD}"
+				for i in "${!BUILT_MODULE_NAME[@]}"; do
+					if [[ ${name} == ${BUILT_MODULE_NAME[${i}]} ]]
+					then
+						echo ${i} || die
+						exit 0
+					fi
+				done
+				echo ${#BUILT_MODULE_NAME[@]} || die
+			) || continue
+		else
+			# If the kernel modules are in a subdir add this to the
+			# DKMS package name identifier to ensure it is unique.
+			# There may be multiple subdirs with kernel modules.
+			if [[ ${PWD} == ${S} ]]; then
+				package=${PN}
+			else
+				package=${PN}_${name}
+			fi
+			cat <<-EOF > dkms.conf || die
+				PACKAGE_NAME=${package}
+				PACKAGE_VERSION=${PV}
+			EOF
+			if [[ -n ${autoinstall} ]]; then
+				echo "AUTOINSTALL=yes" >> dkms.conf || die
+			else
+				echo "AUTOINSTALL=no" >> dkms.conf || die
+			fi
+			index=0
+		fi
+
+		# If there is no MAKE command in this dkms.conf yet, add one
+		if ! grep -qE "^MAKE(\[0\]|)=" dkms.conf; then
+			echo "MAKE[0]=\"${make_command} ${mod[3]}\"" >> dkms.conf || die
+		fi
+
+		# DKMS enforces that the install target starts with one of
+		# these options.
+		local dest=${mod[0]}
+		if ! [[ ${dest} == /kernel* || ${dest} == /updates* ||
+			${dest} == /extra* ]]
+		then
+			dest=/extra/${dest}
+		fi
+
+		# Add one empty line in case upstream provided dkms.conf is
+		# missing a line ending on the final line. Also looks nicer
+		# because now all the settings for each kernel module are
+		# grouped together.
+		cat <<-EOF >> dkms.conf || die
+
+			BUILT_MODULE_NAME[${index}]=${name}
+			BUILT_MODULE_LOCATION[${index}]=.${mod[2]#"${mod[1]%/.}"}/
+			DEST_MODULE_NAME[${index}]=${name}
+			DEST_MODULE_LOCATION[${index}]=${dest}
+		EOF
+		if use strip; then
+			echo "STRIP[${index}]=yes" >> dkms.conf || die
+		else
+			echo "STRIP[${index}]=no" >> dkms.conf || die
+		fi
+
+		# Append this dkms.conf to our tracker array
+		if ! has "${PWD}/dkms.conf" "${dkms_config_files[@]}"; then
+			dkms_config_files+=( "${PWD}/dkms.conf" )
+		fi
+		popd >/dev/null || die
+	done
+
+	# Add the users compiler *FLAGS and MAKEOPTS to all dkms.conf's
+	dkms_gentoofy_conf "${dkms_config_files[@]}"
+}
+
+# @FUNCTION: dkms_dopackage
+# @USAGE: <dkms package root>
+# @DESCRIPTION:
+# Installs a DKMS package to ${ED}/usr/src. If no path is specified
+# as the first argument, then the root of the package is assumed to
+# be the pwd. Appends the installed package to the global
+# DKMS_PACKAGES array. Does nothing if USE=dkms is disabled.
+dkms_dopackage() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	[[ ${#} -gt 1 ]] && die "${FUNCNAME}: too many arguments"
+	local package_root=${1:-"${PWD}"}
+	[[ ${package_root} != /* ]] && package_root=${PWD}/${package_root}
+	[[ -f ${package_root}/dkms.conf ]] ||
+		die "${FUNCNAME}: no DKMS conf at ${package_root}"
+	# subshell to avoid polluting the environment with the dkms.conf.
+	local package="$(
+		source "${package_root}/dkms.conf" &>/dev/null ||
+			die "${FUNCNAME}: invalid DKMS conf at ${package_root}"
+		dest=/usr/src/${PACKAGE_NAME}-${PACKAGE_VERSION}
+		# Replace references to current dir with merged dir
+		sed -i "${package_root}/dkms.conf" \
+			-e "s#${package_root}#${EPREFIX}${dest}#g" || die
+		mkdir -p "${ED}${dest}" || die
+		cp -a "${package_root}"/* "${ED}${dest}" || die
+		modules_process_dracut.conf.d "${BUILT_MODULE_NAME[@]}"
+		echo "${PACKAGE_NAME}:${PACKAGE_VERSION}"
+	)"
+	if has "${package}" "${DKMS_PACKAGES[@]}"; then
+		die "${FUNCNAME}: DKMS package with the same name is already installed"
+	elif [[ ${package} == :* || ${package} == *: ]]; then
+		die "${FUNCNAME}: DKMS conf did not set a package name or version"
+	else
+		DKMS_PACKAGES+=( "${package}" )
+	fi
+}
+
+# @FUNCTION: dkms_src_compile
+# @DESCRIPTION:
+# Runs dkms_autoconf if USE=dkms is enabled, otherwise runs
+# linux-mod-r1_src_compile. Arguments given to this function are
+# passed onto dkms_autoconf.
+dkms_src_compile() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	if ! use dkms; then
+		linux-mod-r1_src_compile
+		return 0
+	fi
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	dkms_autoconf "${@}"
+}
+
+# @FUNCTION: dkms_src_install
+# @DESCRIPTION:
+# Runs dkms_dopackage for each dkms.conf found in the pwd or any
+# sub-directories. Then runs einstalldocs. If USE=dkms is disabled
+# then linux-mod-r1_src_install is run instead.
+dkms_src_install() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	if ! use dkms; then
+		linux-mod-r1_src_install
+		return 0
+	fi
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	while IFS= read -r -d '' file; do
+		dkms_dopackage $(dirname "${file}")
+	done < <(find "${PWD}" -type f -name dkms.conf -print0 || die)
+
+	einstalldocs
+}
+
+# @FUNCTION: dkms_pkg_config
+# @DESCRIPTION:
+# Rebuilds and reinstalls all DKMS packages owned by the ebuild.
+# Does nothing if USE=dkms is disabled.
+dkms_pkg_config() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local package ARCH=$(tc-arch-kernel)
+	for package in "${DKMS_PACKAGES[@]}"; do
+		IFS=: read -ra package <<<"${package#}"
+		[[ ${#package[@]} -eq 2 ]] ||
+			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
+		einfo "Building ${package[0]} version ${package[1]}"
+		dkms build -m ${package[0]} -v ${package[1]} --force ||
+			die "${FUNCNAME}: failed to build ${package} with DKMS"
+		einfo "Installing ${package[0]} version ${package[1]}"
+		dkms install -m ${package[0]} -v ${package[1]} --force ||
+			die "${FUNCNAME}: failed to install ${package} with DKMS"
+	done
+
+	if [[ ${MODULES_INITRAMFS_IUSE} ]] && use dist-kernel &&
+		use ${MODULES_INITRAMFS_IUSE#+}
+	then
+		dist-kernel_reinstall_initramfs "${KV_DIR}" "${KV_FULL}" --all
+	fi
+}
+
+# @FUNCTION: dkms_postinst
+# @DESCRIPTION:
+# Registers, builds and installs all DKMS packages owned by the
+# ebuild. Calls dist-kernel_reinstall_initramfs if requested by the
+# ebuild via linux-mod-r1's MODULES_INITRAMFS_IUSE. Runs
+# linux-mod-r1_pkg_postinst if USE=dkms is disabled.
+dkms_pkg_postinst() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	if ! use dkms; then
+		linux-mod-r1_pkg_postinst
+		return 0
+	fi
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local package ARCH=$(tc-arch-kernel)
+	for package in "${DKMS_PACKAGES[@]}"; do
+		IFS=: read -ra package <<<"${package#}"
+		[[ ${#package[@]} -eq 2 ]] ||
+			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
+		einfo "Registering ${package[0]} version ${package[1]}"
+		dkms add -m ${package[0]} -v ${package[1]} ||
+			die "${FUNCNAME}: failed to register ${package[0]} with DKMS"
+		einfo "Building ${package[0]} version ${package[1]}"
+		dkms build -m ${package[0]} -v ${package[1]} \
+			-k ${KV_FULL} --force ||
+				die "${FUNCNAME}: failed to build ${package[0]} with DKMS"
+		einfo "Installing ${package[0]} version ${package[1]}"
+		dkms install -m ${package[0]} -v ${package[1]} \
+			-k ${KV_FULL} --force ||
+				die "${FUNCNAME}: failed to install ${package[0]} with DKMS"
+	done
+
+	if [[ ${MODULES_INITRAMFS_IUSE} ]] && use dist-kernel &&
+		use ${MODULES_INITRAMFS_IUSE#+}
+	then
+		dist-kernel_reinstall_initramfs "${KV_DIR}" "${KV_FULL}" --all
+	fi
+}
+
+# @FUNCTION: dkms_pkg_prerm
+# @DESCRIPTION:
+# Uninstalls, unbuilds and deregisters all DKMS packages owned by the
+# ebuild. Does nothing if USE=dkms is disabled.
+dkms_pkg_prerm() {
+	debug-print-function ${FUNCNAME} "$@"
+
+	use dkms || return 0
+	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
+		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
+
+	local package ARCH=$(tc-arch-kernel)
+	for package in "${DKMS_PACKAGES[@]}"; do
+		IFS=: read -ra package <<<"${package#}"
+		[[ ${#package[@]} -eq 2 ]] ||
+			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
+		einfo "Uninstalling ${package[0]} version ${package[1]}"
+		dkms uninstall -m ${package[0]} -v ${package[1]} --all ||
+			ewarn "${FUNCNAME}: failed to uninstall ${package[0]} with DKMS"
+		einfo "Unbuilding ${package[0]} version ${package[1]}"
+		dkms unbuild -m ${package[0]} -v ${package[1]} --all ||
+			ewarn "${FUNCNAME}: failed to unbuild ${package[0]} with DKMS"
+		einfo "Deregistering ${package[0]} version ${package[1]}"
+		dkms remove -m ${package[0]} -v ${package[1]} --all ||
+			ewarn "${FUNCNAME}: failed to deregister ${package[0]} with DKMS"
+	done
+}
+
+fi
+
+EXPORT_FUNCTIONS src_compile src_install pkg_config pkg_postinst pkg_prerm
-- 
2.48.1

Re: [gentoo-dev] [PATCH 5/5] dkms.eclass: introduce new eclass

[Alexey Sokolov]

[-- Attachment #1: Type: text/plain, Size: 19295 bytes --]

14.03.2025 12:48, Nowa Ammerlaan пишет:

> Signed-off-by: Nowa Ammerlaan
> [<nowa@gentoo.org>](mailto:nowa@gentoo.org)
> ---
>  eclass/dkms.eclass | 545 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 545 insertions(+)
>  create mode 100644 eclass/dkms.eclass
>
> diff --git a/eclass/dkms.eclass b/eclass/dkms.eclass
> new file mode 100644
> index 000000000000..c445b95721c3
> --- /dev/null
> +++ b/eclass/dkms.eclass
> @@ -0,0 +1,545 @@
> +# Copyright 2025 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: dkms.eclass
> +# @MAINTAINER:
> +# Nowa Ammerlaan
> [<nowa@gentoo.org>](mailto:nowa@gentoo.org)
> +# @AUTHOR:
> +# Author: Nowa Ammerlaan
> [<nowa@gentoo.org>](mailto:nowa@gentoo.org)
> +# @SUPPORTED_EAPIS: 8
> +# @PROVIDES: linux-mod-r1
> +# @BLURB: Helper eclass to manage DKMS modules
> +# @DESCRIPTION:
> +# Registers, builds and installs kernel modules using the DKMS
> +# (Dynamic Kernel Module Support) system provided by sys-kernel/dkms.
> +#
> +# The dkms_autoconf may be used to translate the modlist and modargs
> +# arrays from linux-mod-r1.eclass to a DKMS configuration file.
> +#
> +# If the upstream sources already contain a DKMS configuration file
> +# this may be used instead of the dkms_autoconf function. In this
> +# case dkms_gentoofy_conf function may be used to insert the users
> +# compiler, MAKEOPTS and *FLAGS preferences into the DKMS
> +# configuration file.
> +#
> +# The dkms_dopackage function is used to install a DKMS package, this
> +# function expects to find a dkms.conf file at the path specified
> +# by the argument passed to this function. If not path is specified
> +# the current working directory is used.

typo: if no path is specified

> +#
> +# For convenience this eclass exports a src_compile function that runs
> +# dkms_autoconf if the dkms USE flag is enabled, and if the flag is
> +# disabled it runs linux-mod-r1_src_compile instead. Similarly,
> +# the src_install function exported by this eclass finds any
> +# dkms.conf files in the current working directory or one of its
> +# subdirectories and then calls dkms_dopackage for these packages.
> +# And if the dkms USE flag is disabled it runs
> +# linux-mod-r1_src_install instead.
> +#
> +# The pkg_postinst and pkg_postrm functions then take care of
> +# (de)registering, (un)building, removing, and/or adding the DKMS
> +# packages. For convenience the eclass also exports a pkg_config
> +# function that rebuilds and reinstalls any DKMS packages the ebuild
> +# owns for the currently running kernel.
> +#
> +# @EXAMPLE:
> +#
> +# To add DKMS support to an ebuild currently using only linux-mod-r1.
> +#
> +# Change:
> +#
> +# @CODE
> +# inherit linux-mod-r1
> +#
> +# src_compile() {
> +#     local modlist=(
> +#         gentoo
> +#         gamepad=kernel/drivers/hid:gamepad:gamepad/obj
> +#     )
> +#     local modargs=( NIH_SOURCE="${KV_OUT_DIR}" )
> +#
> +#     linux-mod-r1_src_compile
> +# }
> +# @CODE
> +#
> +# To:
> +#
> +# @CODE
> +# inherit dkms
> +#
> +# src_compile() {
> +#     local modlist=(
> +#         gentoo
> +#         gamepad=kernel/drivers/hid:gamepad:gamepad/obj
> +#     )
> +#     local modargs=( NIH_SOURCE="${KV_OUT_DIR}" )
> +#
> +#     dkms_src_compile
> +# }
> +# @CODE
> +#
> +# Note that due to the inherit order the src_install and pkg_postinst
> +# phase functions may have to be defined explicitly.
> +#
> +# @EXAMPLE:
> +#
> +# A more complex example is the case of an ebuild that is currently
> +# inheriting linux-mod-r1, but is not using any of its phase
> +# functions. In this case there is usually no modlist for
> +# dkms_autoconf to convert into a DKMS configuration file.
> +# Instead the ebuild must utilize a dkms.conf provided by upstream
> +# in the sources, or alternatively create one from scratch and
> +# include it in FILESDIR.
> +#
> +# Tip: Check if there is a rpm/deb spec or similar script that can
> +# create a dkms.conf to find a hint of what it should look like and
> +# where it should be created for this particular package.
> +#
> +# @CODE
> +# inherit dkms linux-mod-r1
> +#
> +# src_prepare() {
> +#   default
> +#   sed -e "s/@VERSION@/${PV}/" -i modules/dkms.conf || die
> +# }
> +#
> +# src_compile() {
> +#     if use dkms; then
> +#         dkms_gentoofy_conf modules/dkms.conf
> +#     else
> +#         emake "${MODULES_MAKEARGS[@]}" modules
> +#     fi
> +# }
> +#
> +# src_install() {
> +#     if use dkms; then
> +#         dkms_dopackage modules
> +#     else
> +#         linux_domodule modules/mymodule.ko
> +#         modules_post_process
> +#     fi
> +#     einstalldocs
> +# }
> +#
> +# pkg_postinst() {
> +#     dkms_pkg_postinst
> +# }
> +# @CODE
> +
> +case ${EAPI} in
> +	8) ;;
> +	*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> +esac
> +
> +if [[ -z ${_DKMS_ECLASS} ]]; then
> +_DKMS_ECLASS=1
> +
> +inherit linux-mod-r1
> +
> +IUSE="dkms"
> +
> +RDEPEND="dkms? ( sys-kernel/dkms ${BDEPEND} )"
> +IDEPEND="dkms? ( sys-kernel/dkms ${BDEPEND} )"
> +
> +# @ECLASS_VARIABLE: DKMS_PACKAGES
> +# @OUTPUT_VARIABLE
> +# @DESCRIPTION:
> +# After dkms_src_install or dkms_dopackage this array will be
> +# populated with all dkms packages installed by the ebuild. The names
> +# and versions of each package are separated with a ':'.
> +DKMS_PACKAGES=()
> +
> +# @FUNCTION: dkms_gentoofy_conf
> +# @USAGE: <list of files>
> +# @DESCRIPTION:
> +# Adds linux-mod-r1's MODULES_MAKEARGS and the ebuilds modargs to any
> +# make calls in an existing dkms.conf. This function must be called
> +# for every dkms.conf that will be installed to ensure that the users
> +# compiler choice and flags are respected by DKMS at runtime.
> +# Multiple files may be passed to this function as arguments. If no
> +# arguments are given than this function runs on the dkms.conf in the
> +# present working directory. Does nothing if USE=dkms is disabled.
> +dkms_gentoofy_conf() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local file input=( "${@}" )
> +	[[ ${#} -eq 0 ]] && input=( dkms.conf )
> +
> +	# This will set edkmsargs
> +	dkms_sanitize_makeargs
> +
> +	for file in "${input[@]}"; do
> +		[[ -f ${file} ]] ||
> +			die "${FUNCNAME}: DKMS conf does not exist: ${file}"
> +
> +		sed -i "${file}" \
> +			-e "/^MAKE/ s:make :make ${edkmsargs[*]} :" \
> +			-e "/^MAKE/ s:make$:make ${edkmsargs[*]}:" \
> +			-e "/^MAKE/ s:make\":make ${edkmsargs[*]}\":" \
> +			-e "/^MAKE/ s:'make' :'make' ${edkmsargs[*]} : " \
> +			-e "/^MAKE/ s:'make'$:'make' ${edkmsargs[*]}:" \
> +			-e "/^MAKE/ s:'make'\":'make' ${edkmsargs[*]}\":" ||
> +				die "${FUNCNAME}: failed to Gentoo'fy ${file}"
> +	done
> +}
> +
> +# @FUNCTION: dkms_sanitize_makeargs
> +# @DESCRIPTION:
> +# Uses linux-mod-r1's MODULES_MAKEARGS and modargs to set the
> +# edkmsargs array. This array contains all variables from the two
> +# input arrays except those referencing the current kernel version.
> +# Quotes are added to the variables to prevent parsing problems at
> +# DKMS runtime. Does nothing if USE=dkms is disabled.
> +dkms_sanitize_makeargs() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local -a args=( "${MODULES_MAKEARGS[@]}" )
> +	[[ ${modargs@a} == *a* ]] && args+=( "${modargs[@]}" )
> +
> +	edkmsargs=( ${MAKEOPTS} )
> +	local arg
> +	for arg in "${args[@]}"; do
> +		# Replace Gentoo kernel targets with DKMS variables
> +		case ${arg} in
> +			*=${KV_OUT_DIR}|*=${KV_DIR})
> +				edkmsargs+=( "${arg%%=*}=\${kernel_source_dir}" )
> +			;;
> +			${KV_OUT_DIR}|${KV_DIR})
> +				edkmsargs+=( "\${kernel_source_dir}" )
> +			;;
> +			*=${KV_FULL})
> +				edkmsargs+=( "${arg%%=*}=\${kernelver}" )
> +			;;
> +			${KV_FULL})
> +				edkmsargs+=( "\${kernelver}" )
> +			;;
> +			*${KV_FULL}*|*${KV_DIR}*|*${KV_OUT_DIR}*)
> +				# Skip other arguments pointing to the current target
> +				continue
> +			;;
> +			*=*)
> +				# Quote values for variables to avoid parsing problems
> +				edkmsargs+=( "${arg%%=*}='${arg#*=}'" )
> +			;;
> +			*)
> +				edkmsargs+=( "${arg}" )
> +			;;
> +		esac
> +	done
> +}
> +
> +# @FUNCTION: dkms_autoconf
> +# @USAGE: [--no-kernelrelease|--no-autoinstall]
> +# @DESCRIPTION:
> +# Uses linux-mod-r1's modlist and modargs to construct a DKMS
> +# configuration file. By default DKMS adds the 'KERNELRELEASE='
> +# variable to all make commands. Some Makefiles will behave
> +# differently when this variable is set, if this leads to problems
> +# pass the --no-kernelrelease argument to this function to suppress
> +# the addition of 'KERNELRELEASE=' to the calls to make at runtime.
> +# By default the created DKMS configuration file will enable
> +# automatic installation of all kernel modules. To disable this add
> +# the --no-autoinstall argument. Does nothing if USE=dkms is disabled.
> +dkms_autoconf() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local arg autoinstall=1 make_command=make
> +	[[ ${#} -gt 2 ]] && die "${FUNCNAME}: too many arguments"
> +	for arg in "${@}"; do
> +		case ${arg} in
> +			--no-kernelrelease)
> +				# Per DKMS manual, quoting disables setting KERNELRELEASE
> +				make_command=\'make\'
> +			;;
> +			--no-autoinstall)
> +				autoinstall=
> +			;;
> +			*)
> +				die "${FUNCNAME}: invalid argument ${arg}"
> +			;;
> +		esac
> +	done
> +
> +	modules_process_modlist
> +
> +	local index mod name package dkms_config_files=()
> +	for mod in "${modlist[@]}"; do
> +		name=${mod%%=*}
> +		mod=${mod#"${name}"}
> +		IFS=: read -ra mod <<<"${mod#=}"
> +
> +		pushd "${mod[1]}" >/dev/null || die
> +		if [[ -f dkms.conf ]]; then
> +			# Find the index of an existing module, else find the
> +			# first available index.
> +			index=$(
> +				source dkms.conf &>/dev/null ||
> +					die "${FUNCNAME}: invalid dkms.conf at ${PWD}"
> +				for i in "${!BUILT_MODULE_NAME[@]}"; do
> +					if [[ ${name} == ${BUILT_MODULE_NAME[${i}]} ]]
> +					then
> +						echo ${i} || die
> +						exit 0
> +					fi
> +				done
> +				echo ${#BUILT_MODULE_NAME[@]} || die
> +			) || continue
> +		else
> +			# If the kernel modules are in a subdir add this to the
> +			# DKMS package name identifier to ensure it is unique.
> +			# There may be multiple subdirs with kernel modules.
> +			if [[ ${PWD} == ${S} ]]; then
> +				package=${PN}
> +			else
> +				package=${PN}_${name}
> +			fi
> +			cat <<-EOF > dkms.conf || die
> +				PACKAGE_NAME=${package}
> +				PACKAGE_VERSION=${PV}
> +			EOF
> +			if [[ -n ${autoinstall} ]]; then
> +				echo "AUTOINSTALL=yes" >> dkms.conf || die
> +			else
> +				echo "AUTOINSTALL=no" >> dkms.conf || die
> +			fi
> +			index=0
> +		fi
> +
> +		# If there is no MAKE command in this dkms.conf yet, add one
> +		if ! grep -qE "^MAKE(\[0\]|)=" dkms.conf; then
> +			echo "MAKE[0]=\"${make_command} ${mod[3]}\"" >> dkms.conf || die
> +		fi
> +
> +		# DKMS enforces that the install target starts with one of
> +		# these options.
> +		local dest=${mod[0]}
> +		if ! [[ ${dest} == /kernel* || ${dest} == /updates* ||
> +			${dest} == /extra* ]]
> +		then
> +			dest=/extra/${dest}
> +		fi
> +
> +		# Add one empty line in case upstream provided dkms.conf is
> +		# missing a line ending on the final line. Also looks nicer
> +		# because now all the settings for each kernel module are
> +		# grouped together.
> +		cat <<-EOF >> dkms.conf || die
> +
> +			BUILT_MODULE_NAME[${index}]=${name}
> +			BUILT_MODULE_LOCATION[${index}]=.${mod[2]#"${mod[1]%/.}"}/
> +			DEST_MODULE_NAME[${index}]=${name}
> +			DEST_MODULE_LOCATION[${index}]=${dest}
> +		EOF
> +		if use strip; then
> +			echo "STRIP[${index}]=yes" >> dkms.conf || die
> +		else
> +			echo "STRIP[${index}]=no" >> dkms.conf || die
> +		fi
> +
> +		# Append this dkms.conf to our tracker array
> +		if ! has "${PWD}/dkms.conf" "${dkms_config_files[@]}"; then
> +			dkms_config_files+=( "${PWD}/dkms.conf" )
> +		fi
> +		popd >/dev/null || die
> +	done
> +
> +	# Add the users compiler *FLAGS and MAKEOPTS to all dkms.conf's
> +	dkms_gentoofy_conf "${dkms_config_files[@]}"
> +}
> +
> +# @FUNCTION: dkms_dopackage
> +# @USAGE: <dkms package root>
> +# @DESCRIPTION:
> +# Installs a DKMS package to ${ED}/usr/src. If no path is specified
> +# as the first argument, then the root of the package is assumed to
> +# be the pwd. Appends the installed package to the global
> +# DKMS_PACKAGES array. Does nothing if USE=dkms is disabled.
> +dkms_dopackage() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	[[ ${#} -gt 1 ]] && die "${FUNCNAME}: too many arguments"
> +	local package_root=${1:-"${PWD}"}
> +	[[ ${package_root} != /* ]] && package_root=${PWD}/${package_root}
> +	[[ -f ${package_root}/dkms.conf ]] ||
> +		die "${FUNCNAME}: no DKMS conf at ${package_root}"
> +	# subshell to avoid polluting the environment with the dkms.conf.
> +	local package="$(
> +		source "${package_root}/dkms.conf" &>/dev/null ||
> +			die "${FUNCNAME}: invalid DKMS conf at ${package_root}"
> +		dest=/usr/src/${PACKAGE_NAME}-${PACKAGE_VERSION}
> +		# Replace references to current dir with merged dir
> +		sed -i "${package_root}/dkms.conf" \
> +			-e "s#${package_root}#${EPREFIX}${dest}#g" || die
> +		mkdir -p "${ED}${dest}" || die
> +		cp -a "${package_root}"/* "${ED}${dest}" || die
> +		modules_process_dracut.conf.d "${BUILT_MODULE_NAME[@]}"
> +		echo "${PACKAGE_NAME}:${PACKAGE_VERSION}"
> +	)"
> +	if has "${package}" "${DKMS_PACKAGES[@]}"; then
> +		die "${FUNCNAME}: DKMS package with the same name is already installed"
> +	elif [[ ${package} == :* || ${package} == *: ]]; then
> +		die "${FUNCNAME}: DKMS conf did not set a package name or version"
> +	else
> +		DKMS_PACKAGES+=( "${package}" )
> +	fi
> +}
> +
> +# @FUNCTION: dkms_src_compile
> +# @DESCRIPTION:
> +# Runs dkms_autoconf if USE=dkms is enabled, otherwise runs
> +# linux-mod-r1_src_compile. Arguments given to this function are
> +# passed onto dkms_autoconf.
> +dkms_src_compile() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	if ! use dkms; then
> +		linux-mod-r1_src_compile
> +		return 0
> +	fi
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	dkms_autoconf "${@}"
> +}
> +
> +# @FUNCTION: dkms_src_install
> +# @DESCRIPTION:
> +# Runs dkms_dopackage for each dkms.conf found in the pwd or any
> +# sub-directories. Then runs einstalldocs. If USE=dkms is disabled
> +# then linux-mod-r1_src_install is run instead.
> +dkms_src_install() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	if ! use dkms; then
> +		linux-mod-r1_src_install
> +		return 0
> +	fi
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	while IFS= read -r -d '' file; do
> +		dkms_dopackage $(dirname "${file}")
> +	done < <(find "${PWD}" -type f -name dkms.conf -print0 || die)
> +
> +	einstalldocs
> +}
> +
> +# @FUNCTION: dkms_pkg_config
> +# @DESCRIPTION:
> +# Rebuilds and reinstalls all DKMS packages owned by the ebuild.
> +# Does nothing if USE=dkms is disabled.
> +dkms_pkg_config() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local package ARCH=$(tc-arch-kernel)
> +	for package in "${DKMS_PACKAGES[@]}"; do
> +		IFS=: read -ra package <<<"${package#}"
> +		[[ ${#package[@]} -eq 2 ]] ||
> +			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
> +		einfo "Building ${package[0]} version ${package[1]}"
> +		dkms build -m ${package[0]} -v ${package[1]} --force ||
> +			die "${FUNCNAME}: failed to build ${package} with DKMS"
> +		einfo "Installing ${package[0]} version ${package[1]}"
> +		dkms install -m ${package[0]} -v ${package[1]} --force ||
> +			die "${FUNCNAME}: failed to install ${package} with DKMS"
> +	done
> +
> +	if [[ ${MODULES_INITRAMFS_IUSE} ]] && use dist-kernel &&
> +		use ${MODULES_INITRAMFS_IUSE#+}
> +	then
> +		dist-kernel_reinstall_initramfs "${KV_DIR}" "${KV_FULL}" --all
> +	fi
> +}
> +
> +# @FUNCTION: dkms_postinst
> +# @DESCRIPTION:
> +# Registers, builds and installs all DKMS packages owned by the
> +# ebuild. Calls dist-kernel_reinstall_initramfs if requested by the
> +# ebuild via linux-mod-r1's MODULES_INITRAMFS_IUSE. Runs
> +# linux-mod-r1_pkg_postinst if USE=dkms is disabled.
> +dkms_pkg_postinst() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	if ! use dkms; then
> +		linux-mod-r1_pkg_postinst
> +		return 0
> +	fi
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local package ARCH=$(tc-arch-kernel)
> +	for package in "${DKMS_PACKAGES[@]}"; do
> +		IFS=: read -ra package <<<"${package#}"
> +		[[ ${#package[@]} -eq 2 ]] ||
> +			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
> +		einfo "Registering ${package[0]} version ${package[1]}"
> +		dkms add -m ${package[0]} -v ${package[1]} ||
> +			die "${FUNCNAME}: failed to register ${package[0]} with DKMS"
> +		einfo "Building ${package[0]} version ${package[1]}"
> +		dkms build -m ${package[0]} -v ${package[1]} \
> +			-k ${KV_FULL} --force ||
> +				die "${FUNCNAME}: failed to build ${package[0]} with DKMS"
> +		einfo "Installing ${package[0]} version ${package[1]}"
> +		dkms install -m ${package[0]} -v ${package[1]} \
> +			-k ${KV_FULL} --force ||
> +				die "${FUNCNAME}: failed to install ${package[0]} with DKMS"
> +	done
> +
> +	if [[ ${MODULES_INITRAMFS_IUSE} ]] && use dist-kernel &&
> +		use ${MODULES_INITRAMFS_IUSE#+}
> +	then
> +		dist-kernel_reinstall_initramfs "${KV_DIR}" "${KV_FULL}" --all
> +	fi
> +}
> +
> +# @FUNCTION: dkms_pkg_prerm
> +# @DESCRIPTION:
> +# Uninstalls, unbuilds and deregisters all DKMS packages owned by the
> +# ebuild. Does nothing if USE=dkms is disabled.
> +dkms_pkg_prerm() {
> +	debug-print-function ${FUNCNAME} "$@"
> +
> +	use dkms || return 0
> +	[[ -z ${MODULES_OPTIONAL_IUSE} ]] ||
> +		use "${MODULES_OPTIONAL_IUSE#+}" || return 0
> +
> +	local package ARCH=$(tc-arch-kernel)
> +	for package in "${DKMS_PACKAGES[@]}"; do
> +		IFS=: read -ra package <<<"${package#}"
> +		[[ ${#package[@]} -eq 2 ]] ||
> +			die "${FUNCNAME}: incorrect package in ${DKMS_PACKAGES[*]}"
> +		einfo "Uninstalling ${package[0]} version ${package[1]}"
> +		dkms uninstall -m ${package[0]} -v ${package[1]} --all ||
> +			ewarn "${FUNCNAME}: failed to uninstall ${package[0]} with DKMS"
> +		einfo "Unbuilding ${package[0]} version ${package[1]}"
> +		dkms unbuild -m ${package[0]} -v ${package[1]} --all ||
> +			ewarn "${FUNCNAME}: failed to unbuild ${package[0]} with DKMS"
> +		einfo "Deregistering ${package[0]} version ${package[1]}"
> +		dkms remove -m ${package[0]} -v ${package[1]} --all ||
> +			ewarn "${FUNCNAME}: failed to deregister ${package[0]} with DKMS"
> +	done
> +}
> +
> +fi
> +
> +EXPORT_FUNCTIONS src_compile src_install pkg_config pkg_postinst pkg_prerm
> --
> 2.48.1

[-- Attachment #2: Type: text/html, Size: 19741 bytes --]

Re: [gentoo-dev] [PATCH 5/5] dkms.eclass: introduce new eclass

[Nowa Ammerlaan]

On 14/03/2025 16:34, Alexey Sokolov wrote:
> 14.03.2025 12:48, Nowa Ammerlaan пишет:
>> Signed-off-by: Nowa Ammerlaan<nowa@gentoo.org>
>> ---
>>   eclass/dkms.eclass | 545 +++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 545 insertions(+)
>>   create mode 100644 eclass/dkms.eclass
>>
>> diff --git a/eclass/dkms.eclass b/eclass/dkms.eclass
>> new file mode 100644
>> index 000000000000..c445b95721c3
>> --- /dev/null
>> +++ b/eclass/dkms.eclass
>> @@ -0,0 +1,545 @@
>> +# Copyright 2025 Gentoo Authors
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +# @ECLASS: dkms.eclass
>> +# @MAINTAINER:
>> +# Nowa Ammerlaan<nowa@gentoo.org>
>> +# @AUTHOR:
>> +# Author: Nowa Ammerlaan<nowa@gentoo.org>
>> +# @SUPPORTED_EAPIS: 8
>> +# @PROVIDES: linux-mod-r1
>> +# @BLURB: Helper eclass to manage DKMS modules
>> +# @DESCRIPTION:
>> +# Registers, builds and installs kernel modules using the DKMS
>> +# (Dynamic Kernel Module Support) system provided by sys-kernel/dkms.
>> +#
>> +# The dkms_autoconf may be used to translate the modlist and modargs
>> +# arrays from linux-mod-r1.eclass to a DKMS configuration file.
>> +#
>> +# If the upstream sources already contain a DKMS configuration file
>> +# this may be used instead of the dkms_autoconf function. In this
>> +# case dkms_gentoofy_conf function may be used to insert the users
>> +# compiler, MAKEOPTS and *FLAGS preferences into the DKMS
>> +# configuration file.
>> +#
>> +# The dkms_dopackage function is used to install a DKMS package, this
>> +# function expects to find a dkms.conf file at the path specified
>> +# by the argument passed to this function. If not path is specified
>> +# the current working directory is used.
> 
> typo: if no path is specified
> 

Thanks, fixed in my pull request.