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. <...> > > * 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. 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. Tru -- Tru Huynh http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210520/32f55b5c/attachment-0003.sig>