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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel