CentOS Looks To Deal With Deprecated Device Support, Out-Of-Tree Kernel Modules

[phoronix]

Phoronix: CentOS Looks To Deal With Deprecated Device Support, Out-Of-Tree Kernel Modules

Being proposed within the CentOS project is a new special interest group for providing kernel modules not otherwise available within CentOS Stream. This would also include changes around where CentOS / Red Hat disable some kernel modules or artificially limit the scope of supported hardware...

https://www.phoronix.com/scan.php?page=news_item&px=CentOS-Kmods-SIG

[skeevy420]

I was when I saw it was limited to GPLv2 modules. My primary use for that would be non-free modules....basically just ZFS....I'm sure the ZoL folks will have a Stream repo of some sort so my needs will likely be met should I ever use CentOS Stream or something based on it.

What out of tree GPL modules are there? Genuinely curious. I don't keep up with that these days.

[mroche]

This is potentially a way of getting BTRFS back into CentOS. There was a verbal discussion about this after the last Dojo with some Hyperscale folks. Because the RHEL 9 kernel will be new enough and Red Hat just disables the BTRFS subsystem, they could potentially maintain that tree themselves in the official RHEL kernel (as long as they don't have to make major changes elsewhere that breaks the RHEL kABI). Presently they maintain their own separate kernel.

It hasn't been proposed to Red Hat yet as far as I'm aware, but it would be cool to see.

Cheers,
Mike

[archkde]

I was when I saw it was limited to GPLv2 modules. My primary use for that would be non-free modules....basically just ZFS....I'm sure the ZoL folks will have a Stream repo of some sort so my needs will likely be met should I ever use CentOS Stream or something based on it.

What out of tree GPL modules are there? Genuinely curious. I don't keep up with that these days.

bbswitch and v4l2loopback come to my mind. Probably there are many more.

[Sonadow]

Another one of those 'what's the point of it' initiatives.

If I need an out of tree kmod, I will be already be building it (for open source kmods like wifi drivers on Github) and installing it regardless of whether it taints the stock CentOS kernel.

And if I need to enable an in-tree kmod, I will have already rebuilt the kernel with those kmods enabled.

It's not like there's even any support official support for CentOS, tainted kernel / custom kerneo or not.

[You-]

I suspect many of those that use Centos wont be looking to recompile anything.

On this forum it is suggested that the users of Centos want a hyper stable system where even bug fix updates must be held back until a point release but they will also be recompiling their own kernels.

There will be some users who find the new proposed functionality useful and others who do not.

Avoiding non-GPL compatible kmods is also sensible.

You have to remember that ZFS is not GPL only because Oracle choose for it to not be so. They have no competitive reason to avoid the GPL as the "other OS", Solaris is not something they care about at all. End users can use ZFS without issue, but for larger users (or distributors like Red Hat), there is an element of risk.

[ssokolow]

What out of tree GPL modules are there? Genuinely curious. I don't keep up with that these days.

The one I know is the vhba kernel component for CDEmu. (If you know Daemon Tools, it's the Linux equivalent.)

[johncall]

I'm looking at you `mpt2sas`
Still rocking an LSI SAS2008 RAID adapter

[gilboa]

I'm looking at you `mpt2sas`
Still rocking an LSI SAS2008 RAID adapter

As well as many older Intel SATA controllers used by v2 Xeon server boards. (E.g. One Intel board, S2600CO2 works, while another S4600LH2, from the same time period and the same C602 chipset, intentionally disabled).