On Thursday, May 20, 2021 2:55 PM, Phil Perry <pperry at elrepo.org> wrote: > At which point I would seriously question the validity of using kmods. A > DKMS-type solution (akmod?) would be more appropriate/beneficial IMHO. > > That said, if you are intending to update packages for each kernel > release, building them as well becomes less of an issue. From where will > you pull your source code? For example, elrepo pulls updated sources > from the RHEL kernel source code at every point release for > drivers/devices that RH has disabled. So if you are updating the driver > source from the matching Stream kernel source code and patching to > reenable disabled drivers (plus fixing any new build issues), the > package will need a version bump and rebuild for every kernel release > anyway which negates much of the advantages of a dkms-type solution. > Because of weak-updates, ELRepo only needs to do this once every 6 > months for RHEL point releases, but you will likely be doing it for > every Stream kernel release. Given the frequency of releases as Stream > ramps up, you'll want to automate as much of this process as you can. > > This is one of the reasons elrepo is not able to support Stream > (massively increased workflow), and I think this is one of the major > challenges you will need to overcome. Because you have access to the > kernel in Stream (or a kernel-plus type offering), I would seriously > consider tying to maintain as much of this as you can in-kernel rather > than as out-of-tree modules. kmods/akmods are great when you have no > alternative, but it's always preferable to do this stuff in-kernel where > you can. I agree that keeping things in-kernel as much as possible keep things much easier and cleaner. However, let's consider the possibility that centosplus goes against an inherent mission goal of Stream. A stated reason why there can never be a CentOS 8 SIG is it would take focus away from Stream. So, is it possible from a matter of policy that a kernel-plus type offering could be treated as taking focus away from the Stream kernel? To be clear, I haven't seen anything that explicitly states we are prohibited from forming a kernel-plus SIG, but for purposes of this discussion with the kmods SIG let's theoretically assume we are. The question then becomes what is the most resilient way to deliver this functionality when the focus is required to be on extending the RHEL-NG kernel instead of being able to fully replace it. I would suggest it would be best to provide both kmod and akmod packages. It would be left up to the end user to decide which package works best for them or to install both. If both are installed and the kmod fails to load then the akmod package could work as a fallback solution. There are advantages to akmod over kmod in several situations but I am uncomfortable with any claim it is universally more beneficial. Akmod makes assumptions about the soundness/availability of a compiler environment being available. I am uneasy about using it for block drivers that needs to be added to the dracut/initrd image for mounting the root file system. For ease of support and reproducing bugs I prefer kmod. At the end of the day, akmod still bring more complexity to the end user side than delivering via kmod.