Current and reliable documentation for kmod

General support questions
afalanga
Posts: 96
Joined: 2013/01/31 00:29:05

Current and reliable documentation for kmod

Post by afalanga » 2019/01/15 23:48:32

I am confused about kmod. I need some clarity. Trying to find current/relevant documentation is something of a fool's errand. I've referenced, heavily, the documentation found here. However, the script kmodtool discussed at that link does not look like the one installed on my 7.5 machine. I had to edit, by trial and error and utilizing help from a colleague, the /usr/lib/rpm/redhat/kmodtool script to work with the kernel module I had to build. (For the curious, I built a kmod for the yet-to-be-integrated TCP Congestion Control algorithm agilesd.)

Frankly, the package builds just fine but there is one bit of curiosity. I originally built the package on a 7.3 machine, but when installing to a 7.5 machine the process fails due to dependency failures. It looks like the kernel symbol tcp_slow_start changed magic values from 7.3 to 7.5. This isn't expected. My understanding is that the kmodtool magic recompiles the module auto-magically when kernel revisions change. Am I misunderstanding something about kmod?

It is frustrating trying to find definitive documentation for kmod. The link I provided above informs one how to make a kmod, but doesn't really explain why one would wish to do so or the advantages to doing so. Plus, it seems that there are various ways one can go about doing what I'm trying to do with kmod: i.e. avoid recompiling every time the kernel changes. It mentions something called DKMS, but this seems to be different. Much time spent trying to find relevant docs (Google) reveals references to something called akmod which is, I think, different than kmod. There is also many references to kmod as a seemingly generic term of kernel module packages because context suggests they have nothing to do with kmodtool and Fedora kmod. This is all very frustrating.

Does anyone know of current and relevant documentation for Modern Red Hat/Fedora releases (docs I found at docs.fedoraproject.org were written against Fedora 9 and they've just released 29)? Is there a specification document detailing how this is supposed to work? Can someone here clear up my ignorance?

Thanks

dunch
Posts: 66
Joined: 2018/11/07 13:48:53
Location: Yorkshire

Re: Current and reliable documentation for kmod

Post by dunch » 2019/01/16 10:38:10

You should really build modules against the kernel you're going to run. Linux is quite paricular about making you do this. There is a RedHat utility called weak-modules that you can use to load a kernel module built on an earlier major release (i.e. a module built on CentOS 7.0 can be loaded in 7.6 using weak-modules) but it is better to build against the kernel you are actually running.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Current and reliable documentation for kmod

Post by TrevorH » 2019/01/16 11:55:40

The whole point of RHEL's stable kernel ABI is so that you can build against one kernel and use it on another. It usually breaks on point releases and does need a rebuild and I suspect that's the issue the OP is hitting.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

dunch
Posts: 66
Joined: 2018/11/07 13:48:53
Location: Yorkshire

Re: Current and reliable documentation for kmod

Post by dunch » 2019/01/16 14:43:04

Well, stable ish. They do add symbols from time to time so there's no guarantee that a module built on (say) 7.6 will load on 7.0. They do make a point of not removing symbols though.

afalanga
Posts: 96
Joined: 2013/01/31 00:29:05

Re: Current and reliable documentation for kmod

Post by afalanga » 2019/01/17 22:23:31

TrevorH wrote:
2019/01/16 11:55:40
The whole point of RHEL's stable kernel ABI is so that you can build against one kernel and use it on another. It usually breaks on point releases and does need a rebuild and I suspect that's the issue the OP is hitting.
As I've been thinking about this more, I think I'm actually hitting a problem of dependencies from the RPM. This is why:
Excerpt from calling rpm dependencies wrote: rpm -qRp kmod-agilesd-0.0.1-1.el7.x86_64.rpm
. . .
kernel(tcp_slow_start) = 0x7b89c155
This is built into the RPM package somehow. An experiment to install with ignoring dependencies, of course, allows the package to install. However, the build process seems to be ignored in this case, or other important processes because a 'modprobe tcp_agilesd' returns that the module doesn't exist even though it was installed to the proper place. Basically, the post install processes for calling depmod were somehow skipped.

However, I think that the dependency issue is from the package and not the kmod system/process itself. I plan to try installing the package to a 7.3 distro and upgrading it to 7.5 and see what happens.

chemal
Posts: 776
Joined: 2013/12/08 19:44:49

Re: Current and reliable documentation for kmod

Post by chemal » 2019/01/17 22:39:42

Symbol tcp_slow_start is not listed in /lib/modules/kabi-current/kabi_whitelist_x86_64. Your module isn't covered by RH's kernel ABI.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Current and reliable documentation for kmod

Post by TrevorH » 2019/01/17 23:39:23

I suspect that just like many of the ELRepo kmod packages, yours will be fine when updating kernels within the same point release and will break on a new one. So if you build against 7.6 then it should be fine all the way through until 7.7 comes out (or until RH accidentally break the KABI next time).
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

chemal
Posts: 776
Joined: 2013/12/08 19:44:49

Re: Current and reliable documentation for kmod

Post by chemal » 2019/01/18 00:13:16

A lot of elrepo's kmod packages use symbols not on the whitelist which defines RH's kABI. All other symbols are not covered by RH's guarantee:

"Once a symbol has been introduced into the kBAI for a particular major release of Red Hat Enterprise Linux it will not be removed, nor will its meaning be changed during that kernel major release's complete life cycle. New symbols are added to the kABI in minor releases of Red Hat Enterprise Linux in order to introduce new features, but Red Hat engineering make sure that it will not affect/modify the already existing symbols in the kABI."

afalanga
Posts: 96
Joined: 2013/01/31 00:29:05

Re: Current and reliable documentation for kmod

Post by afalanga » 2019/01/18 15:32:28

TrevorH wrote:
2019/01/17 23:39:23
I suspect that just like many of the ELRepo kmod packages, yours will be fine when updating kernels within the same point release and will break on a new one. So if you build against 7.6 then it should be fine all the way through until 7.7 comes out (or until RH accidentally break the KABI next time).
Trevor, thank you for this insight. It seems I may have naively assumed too much once again. I had assumed that any module built for a 7.x release would update itself correctly within, say, 7.3, and then 7.3 -> 7.4. However, your statement seems to negate this. So, it should be expected that a kmod built on 7.3 may fail to install, and even rebuild, in 7.5?

afalanga
Posts: 96
Joined: 2013/01/31 00:29:05

Re: Current and reliable documentation for kmod

Post by afalanga » 2019/01/18 15:33:41

chemal wrote:
2019/01/18 00:13:16
A lot of elrepo's kmod packages use symbols not on the whitelist which defines RH's kABI. All other symbols are not covered by RH's guarantee:

"Once a symbol has been introduced into the kBAI for a particular major release of Red Hat Enterprise Linux it will not be removed, nor will its meaning be changed during that kernel major release's complete life cycle. New symbols are added to the kABI in minor releases of Red Hat Enterprise Linux in order to introduce new features, but Red Hat engineering make sure that it will not affect/modify the already existing symbols in the kABI."
This is good. Thank you. From what Trevor says, it would seem that Red Hat isn't always able to keep this policy.

Post Reply