On 20/05/2021 21.55, Phil Perry wrote: > 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. Just to make sure we are on the same page: We are talking about in-kernel modules here that are not enabled in RHEL or have some devices/adapters removed (i.e. the first two groups described in the proposal). Yes, the idea is to always use the updated kernel source code and apply patches on top. This is what I have already done for some packages ~3 months ago. So far I only had to update the patches for one module. For all other modules the update could be scripted. However the frequency of CentOS Stream 8 kernel releases has not been that high lately. IMHO for rebuilding kernel modules with deprecated adapters this is the only really safe option you have anyway (apart from the kernel-plus approach): The current ELRepo approach of pulling source code once for every minor release might run into issues in case these sources being updated in a later kernel update to this particular minor release. It is unlikely to happen, even more unlikely to cause any real issues, but possible. > 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's also why I added in the proposal that it is desired to work with upstream to directly get anything possible into CentOS Stream kernel. However, we all know that this is not feasible for all modules. IMHO this is especially not an option for modules of the first group (deprecated adapters). Although some people suggested to try to revert the removal of deprecated adapters in the CentOS Stream kernel, I do not see this happening. Afterall it is still Red Hat deciding what's going into the CentOS Stream kernel. kernel-plus is of course an option, especially to re-enable support for deprecated adapters. However there are use cases where you simply can not replace the kernel with kernel-plus (or have to use some otherwise patched kernel). In these cases the only feasible option (IMHO) is to use external kernel modules. But there is obviously a large overlap (especially for the first and second group of modules) between kernel-plus and this proposed SIG. Hence I hope both efforts can work closely together. > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel