[CentOS-devel] (How) do others SIGs provide kernel modules?

[Phil Perry]

On 07/10/18 10:58, Manuel Wolfshant wrote:
> On October 7, 2018 12:37:37 PM GMT+03:00, Niels de Vos <ndevos at redhat.com> wrote:
>> Hi,
>>
>> There is an oustanding request for the Storage SIG to package and
>> provide VDO:
>>
>>> VDO (which includes kvdo and vdo) is software that provides inline
>>> block-level deduplication, compression, and thin provisioning
>>> capabilities for primary storage.
>>
>> Both components ate packaged in a Fedora COPR, and a reasonable .spec
>> file is provided by the upstream project.
>>
>> However, the kernel module is packaged with DKMS. This would result in
>> building the module during RPM installation, and possibly on reboot
>> after a kernel update.
>>
>> There is a dkms package in the CBS (by Haïkel), but it is only tagged
>> with -candidate. I would like to know what the reasons were to not
>> consumer it for a release.
>>
>> It seems that there is one (that I could find) package in the CBS that
>> provides a kernel modules (openafs-kmod by Jonathan). It utilizes DKMS
>> as well, but also never made it a repository for release.
>>
>> Then there is the kmod package (build by Lokesh). This is an
>> alternative
>> way of building kernel modules. It compiles the module in the CBS, for
>> a
>> specific (sortof major) kernel version. The resulting RPM can then be
>> installed without the need to build it again.
>>
>> My personal preference would be to provide kernel modules with the kmod
>> practise. But I love to hear opinions and experiences from others.
>>
> 
> dkms requires the presence of compiler and a ton of devel packages . I prefer to not have any of those on servers. So +1 for kmods
> 
> Wolfy, former packager of ath and realtek modules in dkms format

You have your answer, but I'll add to Wolfy's response above if I may.

The RHEL way of packaging kernel modules is to use kmods under the 
Driver Update Programme infrastructure which exists for exactly this 
purpose, taking advantage of the stable kABI that exists in RHEL kernels.

Please don't be tempted to follow or refer to the various concoctions of 
methods derived from Fedora which doesn't have a stable kABI and were 
devised to solve issues that simply don't exist in RHEL. Use the tools 
Red Hat provides in RHEL - kmods are the accepted way of packaging 
kernel modules in RHEL.