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