Efforts to get this module into EPEL or main kernel tree

[marqrdt]

Not a bug, but this appears to be a good forum for communication.
I work for a large federal agency and am part of an effort to make Red Hat Linux 8 and/or 9 available in a DaaS (Desktop As A Service) through VMWare. We would potentially have a few thousand users. VMWare calls out this module in their documentation.
It is required for redirecting audio and video to local USB devices on the host system.

Our dilemma is that Red Hat is the only fully-approved and supported Linux distro on our networks because of their extensive support for and deployment across federal agencies. Red Hat does not support DKMS (sorry-- login is required. Basic summary: Red Hat does not support DKMS), but it is available through EPEL. We're authorized to use EPEL, but for such a large project, that might pose difficulties in support. I see that it is available as a DKMS module in Ubuntu main. We do support some Ubuntu but would not be able to roll it out on such a large project. RHEL9 is built from 5.14, and IMHO it might be too late in the RHEL8 cycle to work with the 4.18 tree that it is built from. It's at 8.6, and .10 will be the final release.

My question: Have you considered requesting this module to be available in the main linux kernel tree? Or, as an alternative, submitting it to EPEL? The fact that an organization as large as VMWare documents its use is interesting to note.

Thank you for providing this piece of software.

[BenBE]

NB: I'm not a maintainer here, but given that (together with some other folks) we are currently doing some reviewing of the module code, I'll give a short summary from my point of view.

The initial review from our group was triggered by an issue I noticed while using this module as backend for some project. While we were reviewing we noticed several overall patterns in the code that are likely to cause rejection from the core Linux developers, as they arise from structural issues (won't go into details for now, corresponding issue reports will follow, once our review group cross-checked them properly). But as issues like the one that triggered the release of 0.12.6 recently were spotted without too much effort (i.e. in plain sight while reading the code) and one whole class of issues currently still postponed by our group, I personally would recommend against this module being an integral part of the default kernel tree just yet.

On the other hand, having this module available in DKMS or as an additional package for your distribution seems reasonable, but comes with the same (code quality/security) caveat, but in a somewhat lesser form: It allows for somewhat better gauging of the risk that adding an additional module brings, as the code right now is well within the range of reviewing (about 3000 LOC can be done reasonably in about a week full-time), while as a part of the kernel tree this might be much less visible scope-wise. In the end packaging mostly depends on finding a maintainer for your distribution to cater for the packages and keeping them current, looking through (distro-specific) issues and overall handling the communication with distro processes. I'm not sure about the status for EPEL in that regard (using DKMS in Debian/Ubuntu).

IIRC there's at least issue #268 with some more information about upstreaming this module into the mainline Linux kernel tree. The information may be dated, but should otherwise give a good starting point.

[umlaeute]

1. re:upstreaming to mainline kernel - this is a dupe of submit v4l2loopback to the upstream kernel #268
2. re EPEL: i did not have this on my radar (as I have a heavy Debian background). but I agree with @BenBE that you (or whoever is interested in having this software as part of some distribution - even via an "extra" repository) just need to find a maintainer for your distribution to take care of it. i believe that upstreams are typically not the best maintainers. i just happen to be a DebianDeveloper 😋

[FelixSchwarz]

Just to provide some additional information from the Fedora/EPEL background: Fedora (including EPEL) does not allow packaging external kernel modules.

EPEL policy:

Kernel modules are not allowed, as they can disturb the base kernel easily.

Fedora policy:

Fedora does not allow kernel modules to be packaged outside of the main kernel package. You should communicate with the Kernel Team regarding enabling additional kernel modules.

You could create a custom DKMS module and/or use COPR but obviously you need to trust the COPR provider then.

[kwizart]

FYI, v4l2loopback is available via the community based rpmfusion-free repository
https://koji.rpmfusion.org/koji/packageinfo?packageID=625
https://koji.rpmfusion.org/koji/packageinfo?packageID=624

You can fetch the the packages pre-built kmod for the given RHEL (or derivates) distro.
For CentOS Stream we only support using akmod-v4l2loopback given how changeable ABI is on this kernel.

Thanks for your understanding.