Re: Modules ??

From: Keith Owens (kaos@ocs.com.au)
Date: Tue Jan 11 2000 - 23:12:26 EST


On Tue, 11 Jan 2000 16:22:24 +0530,
"Syed Khader Vali" <sidcarter@mailcity.com> wrote:
>This might look very silly as I am learning the
>kernel internals just now. Is it possible that
>I can create a module that works with any
>version of the kernel ( for 2.2.xx kernels and beyond ) without meddling with the kernel.

By default insmod will not load a module compiled for kernel 2.2.x into
kernel 2.2.y. You can do "insmod -f" to bypass this kernel version
check. But there are absolutely no guarantees that the module will
work. If any kernel interface, structure and in some cases, config
option has changed then the module and the kernel are out of sync and
sooner or later it will break.

Some examples: modules compiled for SMP cannot be safely loaded into a
kernel compiled without SMP and vice versa. Far too many structures
change in size when SMP is changed. On 2.2 kernels, a module compiled
with > 1Gb support will not work on a kernel with 1Gb support and vice
versa. A block device driver module compiled for 2.3.30 will fail
miserably on 2.3.39 because the block driver interface changed.

If you absolutely must ship a binary module to multiple kernel levels,
try using kernel symbols (genksyms). Each kernel symbol is assigned a
checksum based on its size, its type(s), its return value etc., any
change that affects a kernel symbol should change its checksum. With
genskyms support, insmod will tell you if the module and kernel symbols
are incompatible and refuse to load. The problem with genksyms is that
not all users compile their kernels with this option.

Shipping binary only modules is a *BAD* idea. Look at vmware, they
have a source component which sits between the kernel and their binary
code to hide the kernel differences. It lets them ship a binary only
module but nobody on any Linux list will look at any bug report that
includes vmware. We have no way of telling what the vmware module has
done to the kernel so we cannot diagnose the fault.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:19 EST