I think the truth here is that Fedora packagers don't much care about out of tree kernel modules. It's not something we spend a lot of time thinking about or discussing. I wonder what's stopping this kernel module from going upstream? That's the best way to resolve this. He mentions in the other blog posting that it's an out of tree patch required to read motherboard sensors, which doesn't sound to me like anything controversial.
However this does seem like it's a bug so maybe Chris would be better off filing a Bugzilla rather than ranting. He says:
> I would file a bug report but I cannot imagine that Fedora would accept it. They already know that this feature doesn't work
which may or may not be true ("Fedora" is not a monolithic entity, but a group of packagers with many different opinions). I think he should file the bug anyway, and at the same time work with the upstream kernel community to get the sensors patch into the mainline.
There is an old version of it in the kernel, which doesn't support newer released versions of that chip. I remember reading somewhere that the maintainer was being swamped with requests to make support for those chips too, but didn't get any help for it and it became a toxic environment to work on. So he dropped it.
>I think the truth here is that Fedora packagers don't much care about out of tree kernel modules. It's not something we spend a lot of time thinking about or discussing
This is not entirely true. There is not much we can do about out of tree modules when they don't work with the latest kernel version for whatever reason. If the issue is in our packaging, I do try to keep things working. For instance, we added a number of deps to kernel-devel for 5.12 because what was there was not adequate for 'make prepare' to run, which was required for some modules.
> I would file a bug report but I cannot imagine that Fedora would accept it.
Weak modules was shipped with Fedora to allow some testing for certain scenarios as things go forward. There was already a bug filed that it took too long to run on major kernel updates, so the call to the script was removed from the kernel post. Had someone filed a bug on this, it would have been looked at as well, and likely your module would just work instead of wasting time to write a blog post about how something is broken that you can't even be bother to file a bug over.
- The Fedora Kernel Maintainer who actually reads every bug filed against the Fedora kernel
If I’m understanding this correctly, this is actually a feature that was developed for RHEL and just happens to be enabled on Fedora by accident.
RHEL has a stable kernel ABI because they support third-party binary modules such as from SGI.
Since the kernel ABI is stable, there is no need to rebuild DKMS modules on every kernel update.
FWIW, Debian has a similar mechanism which uses stable kernel ABIs. That’s why a Debian kernel image has always two version numbers, one for the ABI and one for the actual kernel version.
DKMS modules on Debian are rebuilt only when the ABI version changes. It probably uses the same DKMS feature as RHEL, not sure.
I don't think things like this happen deliberately. To trigger this, you need to have a custom module without that specified indicator, and then you need to boot your previous kernel and notice that the module wasn't loaded. That are a lot of steps to get there which most people won't do.
Maybe kernel developers would get in this situation, but even then they'd probably had their system setup better for their situation (and maybe gone through that same process and thought it was part of the setup steps).
[+] [-] rwmj|4 years ago|reply
However this does seem like it's a bug so maybe Chris would be better off filing a Bugzilla rather than ranting. He says:
> I would file a bug report but I cannot imagine that Fedora would accept it. They already know that this feature doesn't work
which may or may not be true ("Fedora" is not a monolithic entity, but a group of packagers with many different opinions). I think he should file the bug anyway, and at the same time work with the upstream kernel community to get the sensors patch into the mainline.
[+] [-] Sjonny|4 years ago|reply
There is an old version of it in the kernel, which doesn't support newer released versions of that chip. I remember reading somewhere that the maintainer was being swamped with requests to make support for those chips too, but didn't get any help for it and it became a toxic environment to work on. So he dropped it.
[+] [-] jforbes_fedora|4 years ago|reply
This is not entirely true. There is not much we can do about out of tree modules when they don't work with the latest kernel version for whatever reason. If the issue is in our packaging, I do try to keep things working. For instance, we added a number of deps to kernel-devel for 5.12 because what was there was not adequate for 'make prepare' to run, which was required for some modules.
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] jforbes_fedora|4 years ago|reply
> I would file a bug report but I cannot imagine that Fedora would accept it.
Weak modules was shipped with Fedora to allow some testing for certain scenarios as things go forward. There was already a bug filed that it took too long to run on major kernel updates, so the call to the script was removed from the kernel post. Had someone filed a bug on this, it would have been looked at as well, and likely your module would just work instead of wasting time to write a blog post about how something is broken that you can't even be bother to file a bug over.
- The Fedora Kernel Maintainer who actually reads every bug filed against the Fedora kernel
[+] [-] mjw1007|4 years ago|reply
[+] [-] cbmuser|4 years ago|reply
RHEL has a stable kernel ABI because they support third-party binary modules such as from SGI.
Since the kernel ABI is stable, there is no need to rebuild DKMS modules on every kernel update.
FWIW, Debian has a similar mechanism which uses stable kernel ABIs. That’s why a Debian kernel image has always two version numbers, one for the ABI and one for the actual kernel version.
DKMS modules on Debian are rebuilt only when the ABI version changes. It probably uses the same DKMS feature as RHEL, not sure.
[+] [-] Bancakes|4 years ago|reply
[+] [-] aneutron|4 years ago|reply
[+] [-] Sjonny|4 years ago|reply
Maybe kernel developers would get in this situation, but even then they'd probably had their system setup better for their situation (and maybe gone through that same process and thought it was part of the setup steps).
[+] [-] cozzyd|4 years ago|reply
[+] [-] encryptluks2|4 years ago|reply
[+] [-] EdwardDiego|4 years ago|reply
[+] [-] teddyh|4 years ago|reply