On 20/05/2021 19:26, Peter Georg wrote: > On 20/05/2021 18.27, Tru Huynh wrote: >> Hi, >> >> chiming in too >> >> On Thu, May 20, 2021 at 03:22:16PM +0000, Patrick Riehecky wrote: >>> Adding notes in line below: >>> >>> On Wed, 2021-05-19 at 17:56 +0200, Peter Georg wrote: >> <...> >>>> Proposal: >>>> = kmods SIG = >>>> >>>> == Goals == >>>> The kmods SIG will focus on providing kernel modules currently not >>>> available in CentOS Stream. >>>> >>>> == Status == >>>> Proposed: RFC and looking for a sponsoring Governing Board member >>> >>> As a board member I hereby indicate a willingness to sponsor. If >>> another board member is passionate about this, I'll be happy to hand it >>> over to them. I've regularly made use of external kmods (for old >>> hardware and proprietary hardware)and would strongly like to see them >>> continue in Stream! >> >> +1 >> >> Emphasizing the possible issues: >> Since we won't have garanteed stable kernel ABI, >> so weak-updates may not always work, so that would imply building >> (all) kmod for each kernel release. Also that would mean extra care >> when the kmod version for a given driver is upgraded along with a newer >> kernel is installed. >> If that can be achieved, elrepo kmod will benefit from this work, >> done in Stream. >> >> Best effort should be emphasized, volonteered work, thing may break >> etc... Make sure users expectation VS reality is covered. > > This issue has been discussed previously on this list. From experience > reported by Phil Perry with CentOS Stream kernel updates, weak-updates > are not an option. So yes, all kmods have to be rebuilt for each kernel > release. > 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.