On 2/5/2018 12:31 PM, Stephan Wiesand wrote: > the usual way to use DKMS is to either have it build a module for a newly > installed kernel or install a prebuilt module for that kernel. It may be > possible to abuse it for providing a module built for another kernel, but > I think that won't happen accidentally. > > You may be confusing DKMS with RHEL's "KABI tracking kmods". Those should > be safe to use within a RHEL minor release (and the SL packaging has been > using them like this since EL6.4), but aren't across minor releases (and > that's why the SL packaging modifies the kmod handling to require a build > for the minor release in question.
On RHEL DKMS and KABI are tightly related because of the way in which Red Hat engineers back port feature and functionality changes. During mainline kernel development a change is likely to break an existing interface. Doing so is encouraged so that compilation errors will identify where code modifications are required. On RHEL there is a strong desire to maintain KABI compatibility. Whenever possible, backports are altered to preserve the existing binary interfaces at the risk of changing the interface semantics. As a result, compilation failures do not occur but semantic differences can result in breakage for third party kernel modules that have not been modified at the source level to be aware of the change. The breakage of OpenAFS by RHEL 7.4 and 7.5 (minor releases) were both due to back porting functionality in this manner. Such incompatibilities can result in system panics or silent data corruption depending upon the change. Jeffrey Altman AuriStor, Inc.
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
