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

On 02/06/2021 16.00, Jonathan Billings wrote:
> On Wed, Jun 02, 2021 at 03:30:04PM +0200, Peter Georg wrote:
>> This looks like a really good example of what can be done within the scope
>> of the proposed kmods SIG.
> 
> I'm already building test c9s kernels using this commit:
> https://gitlab.com/jsbillings/kernel/-/commit/eca86bdce910a83ff3b438c67e19f66bf5e3f228
> 
> I'd love to see how people are building the modules as separate
> packages rather than a whole new kernel (which takes a bit of time and
> CPU resources).

There are different approaches how to do this. Currently I use the 
following approach to compile in-tree kernel modules disabled in EL:

* Get the kernel sources

* Modify the Makefile of the driver I'm interested in to enable it. This 
mainly means adding configs/compile flags as desired.

* Apply any required patches/backports to the driver I'm interested in.
Backports are required as Red Hat's backports to the kernel often break 
drivers they are not interested in.
(Note for future: As the Centos Stream 9 kernel is developed openly on 
GitLab, we might try to get these backports directly into the kernel 
sources and not apply patches for every pacakge build.)

* Directly invoke the driver's Makefile, e.g.
make -C /usr/src/kernels/4.18.0-301.1.el8.x86_64 M=$PWD modules

I do all of that in a spec file similar to the Guidelines for 
KernelModules used by RPM Fusion [1].


Once the SIG has been approved I suggest to add a simple driver for each 
group of kernel modules. Once we are happy with these, we can use them 
as templates for similar modules. My suggestion for the first kernel 
modules is:
- megaraid_sas and/or mlx4 for a kernel module with deprecated devices
- isci for an in-tree  kernel module not enabled in EL
- wireguard for an out-of-tree kernel module (EL8 only)

 From a packaging point of view the afs kernel module will look very 
similar to the isci kernel module.


[1]: https://rpmfusion.org/Packaging/KernelModules/Kmods2