BenBE
commented
2 years ago 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
FelixSchwarz
kwizart
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.