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. > <...> >>> * Third-party kernel modules with non compatible license >>> >> >> Echoing other thoughts, packages in EPEL should be installable by folks >> with or without the SIG. So I'd suggest anything that isn't dependent >> on the kmods, should go into EPEL, but things that are kmod specific >> should probably stay within the SIG. In theory, if userspace is tied >> to the kmod, synchronizing updates would be cleaner if things were in >> just the one place. >> >> I'm a bit concerned that "non compatible license" is a bit vague. >> Would this exclude DRBD, ZFS on Linux, OpenAFS, or nVidia? The nVidia >> bits seem to be 'yes, it is excluded', I'm less sure on the other two. >> > Not sure how useful is stream in the HPC world without nvidia drivers. My background is in HPC. Last time I checked I was able to get the nvidia drivers to work with CentOS Stream. But it is even useful without the nvidia drivers. Not every HPC cluster includes nVidia GPUs. > Zfsonlinux is already taken care by them, afaik. > >>> == Roadmap == >>> * Provide packages for in-kernel modules with restored support for >>> deprecated devices >>> * Provide packages for in-kernel modules that have been supported >>> in >>> older CentOS major releases >>> * Provide packages for further beneficial kernel modules requested >>> by >>> the community >>> >> >> I'd add to the roadmap, establish a strong dialog with our friends at >> ELRepo. In a perfect world we can get all the Stream kmods and RHEL >> kmods built under one process so folks don't need to duplicate effort >> .... in practice..... the shorter lifecycle of stream is a bit of an >> adventure here. > +1 > > If there are people willing to do it, +1 for this SIG. > I am just a little worried by the possible amount of effort needed. I hope that this proposal attracts people willing to join this effort. > Tru > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel >