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

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.

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.