Kurz gesagt :Sie kaum kann nützliche Kernel-Module schreiben, die in Kernel relativ vieler Versionen geladen werden können.
Wenn Sie das Modul gegen den Kernel bauen, der mit CONFIG_MODVERSIONS kompiliert wurde (wie in Ihrem Fall) wird für jedes Symbol, das aus dem Kernel exportiert wird, CRC für dieses Symbol in der Moduldatei gespeichert. CRC ist eine Art Kontrollsumme , das unter anderem das Layout von Typen berücksichtigt, die für Funktionsparameter verwendet werden. Zum Beispiel, wenn das Layout eines hypothetischen struct A unterscheidet sich in zwei Kernen, CRC für Funktion f(struct A *a) in diesen Kerneln unterscheidet sich auch.
Wenn ein Modul in den laufenden Kernel geladen wird, werden CRC für alle Funktionen im Modul mit denen für den Kernel verglichen. Wenn sie sich unterscheiden, weigert sich der Kernel, das Modul zu laden. Weitere Informationen zu diesem Mechanismus finden Sie in der Kernel-Dokumentation (Documentation/kbuild/modules.txt).
Um also ein Modul in zwei verschiedene Kernel ladbar zu machen, sind Sie nur auf Funktionen beschränkt, deren Parameter in beiden Kerneln das gleiche Layout haben. Insbesondere bei Layouts vom Typ struct module unterscheidet, kann kein einzelnes Modul für beide Kernel geladen werden.
Es gibt mehrere Ansätze, einen Treiber bereitzustellen, der für mehrere Kernel geeignet ist. Am einfachsten ist es, die Quellen des Treibers zu liefern und fügen Sie sie zu dkms hinzu . Wenn also der laufende Kernel den Treiber nicht eingebaut hat, wird der Treiber automatisch kompiliert unter Verwendung seiner Quellen.