#12 Tracking potential kmods for c9s
Closed 5 months ago by pjgeorg. Opened a year ago by jsbillings.

I'd like to keep track of what would be a good target kmod package to build for c9s now that it has been tagged. Current packages will be included when appropriate.

One source of new kmods would be to diff the Kconfig from c8s to c9s and see what was removed/disabled.


The following packages are potential candidates for c9s. For all these kmods support for devices has been limited by RH:

kmod-aacraid
kmod-be2iscsi
kmod-be2net
kmod-hpsa
kmod-lpfc
kmod-megaraid_sas
kmod-mlx4
kmod-mpt3sas
kmod-mptsas
kmod-mptspi
kmod-qla2xxx
kmod-qla4xxx

I can take care of these.

Two potential kmods for c9s:

  • ntfs3 (added in 5.15)
  • rtw89 (added in 5.16)

As both kmods are fairly new let's wait some time and see if Red Hat adds these anyway.

In case it is required rtw89 might also be a candidate for c8(s). We already provide ntfs3 for c8(s).

Another potential kmod for c9s (of personal interest): acer_wireless

I opened a bug to get it enabled in el9: bz2025985

Hint: Once MR 163 is merged and part of the buildroot we should be able to build kABI tracking kmods for c9s.

I'd love to see ecryptfs back in the mix.

I'd love to see ecryptfs back in the mix.

Sure, see:
https://pagure.io/centos-sig-kmods/kmod-ecryptfs
https://cbs.centos.org/koji/taskinfo?taskID=2636330
https://cbs.centos.org/koji/taskinfo?taskID=2636334
https://cbs.centos.org/koji/taskinfo?taskID=2636336

I need to request kmod-ecryptfs project to be created on git.c.o before I can do proper non-scratch builds.

In addition ecryptfs-utils is required. I prefer to get it into epel8 and epel9 instead of building as part of the kmods SIG. Thoughts?

Having the userspace stuff in EPEL sounds workable to me. In theory folks running non-stream would also benefit from having them there - they'll just need the kmod.

I think it's a bad idea to have packages in EPEL that are useless out of the box.

I think it's a bad idea to have packages in EPEL that are useless out of the box.

I understand your reasoning and can't really argue against it.

I've been hesitant to add user space packages since it seems there is no agreed guideline concerning adding such packages to EPEL.
E.g. exfatprogs and wireguard-tools are in EPEL 7 and 8 although these packages are probably not of much use without the corresponding kernel modules which are both not available in EL7 and EL8 (added in EL9).
I do not know about any other similar user space packages added to EPEL, but there might be more. For other user space packages, e.g. btrfs-progs and ecryptfs-utils maintainers argue that these are useless out of the box and hence shall not be added to EPEL.

I currently tend towards adding all these user space packages to the kmods SIG's repositories for el9.

What do you think? @jsbillings @jcpunk

Currently missing for kmods we provide: btrfs-progs, ecryptfs-utils, and virtualbox-guest-additions.

E.g. exfatprogs and wireguard-tools are in EPEL 7 and 8 although these packages are probably not of much use without the corresponding kernel modules which are both not available in EL7 and EL8 (added in EL9).

I suspect those were put there out of a lack of anywhere else to put them. Now that there is a place, I don't think it'll proliferate.

Two potential kmods for c9s:

  • ntfs3 (added in 5.15)
  • rtw89 (added in 5.16)

As both kmods are fairly new let's wait some time and see if Red Hat adds these anyway.

In case it is required rtw89 might also be a candidate for c8(s). We already provide ntfs3 for c8(s).

Did anyone file a request for these to be backported to the RHEL kernel for c9s?

Two potential kmods for c9s:

  • ntfs3 (added in 5.15)
  • rtw89 (added in 5.16)

As both kmods are fairly new let's wait some time and see if Red Hat adds these anyway.

In case it is required rtw89 might also be a candidate for c8(s). We already provide ntfs3 for c8(s).

Did anyone file a request for these to be backported to the RHEL kernel for c9s?

Not yet. Still on my To-Do list. Next to other stuff I finally want to get finished.

I'm fine with putting the userspace packages wherever feels right. On the one hand, having them in EPEL means other folks don't need to build them too, but, on the other, having packages in EPEL that by definition don't work is a bit odd - and if they've not got EPEL enabled they'd have to host them anyway.

Having things somewhat self contained feels like the right way to go.

At least one of the user space package has BuildRequires (and probably Requires) not available in el9. I obviously do not want to add all these dependencies to our repositories.

Hence I suggest to do as following:

  1. Request epel9 and epel9-next to be added to kmods9s-packages-main-el9s-build (not required for the -rebuild build target).
  2. Build user space packages for kmods we provide in tag kmods9s-packages-main
  3. Two possible options:
    3.1. Add documentation that some of our packages depend on EPEL and link to their doc how to enable.
    3.2. Add Requires: epel-release to centos-release-kmods
    3.3. Add Requires: epel-release to centos-release-kmods and triggers to verify that crb is enabled.

Concerning the three options for 3:
The option 3.2 is probably more confusing for users than the first one when they try to install packages from epel that depend on crb.
I do not like option 3.3 at all. centos-release-kmods should not tamper with configs owned by other packages.

So in my opinion 3.1 is the best choice we have.

One could argue that the best possible solution is to have epel-release take care of enabling crb. But that's not our decision to make.

3.1 and 3.2 both make sense to me. I don't really see 3.3 as a workable starting point. It gets to be messy with rpm verify, folks doing audits of what repos they're using, and config management systems.

3.1. Add documentation that some of our packages depend on EPEL and link to their doc how to enable.
3.2. Add Requires: epel-release to centos-release-kmods

Other possible option (which I personally prefer by now): 3.1 + Recommends: epel-release

We use 3.2 with Hyperscale, and that works for us.

Update on some of the kmods listed here for c9s or we talked about previously somewhere else:

  • acer_wireless: Already enabled in ARK, MR for c9s open (BZ 2025985)
  • kafs: Will be added to c9s as part of Partner Supported GPL module (BZ 2038999 and ARK !1603)
  • ntfs3: Request to include in c9s upstream kernel tree declined (BZ 2050956)
  • rtw89: Included in the next wireless update (BZ 2043454)

This issue was used to identify an initial batch of kmods to be built for c9s. The initial batch of kmods has been release few months ago. For further request independent issues should be opened. Closing this issue.

Metadata Update from @pjgeorg:
- Issue status updated to: Closed (was: Open)

5 months ago

Login to comment on this ticket.

Metadata