[CentOS-devel] [EXT] Re: RFC: kmods SIG Proposal

Thu May 20 18:26:25 UTC 2021
Peter Georg <peter.georg at physik.uni-regensburg.de>

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 

> <...>
>>> * 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