I noticed that the kernel package has a vermagic as the last component
of the version. Module packages depend on the specific version of
kernel package, such that if you change the kernel config, you cannot
install (opkg rejects) module packages built with the new config, on a
system with the old kernel package.
I suspect this is to prevent binary incompatibility which could crash
the system at the kernel level. This makes sense. But you also cannot
build and install new kernel modules after the first kernel build
(which is part of the main purpose of modules). For instance I did not
build kmod-nfnetlink and kmod-nfnetlink-queue at first, but now I wish
to install them (some usermode package depends on them). In reality
the module files are perfectly compatible because I have not changed
any other kernel options beside enabling those two modules.
The vermagic is computed like this [1]:
$(SH_FUNC) grep '=[ym]' $(LINUX_DIR)/.config | LC_ALL=C sort | md5s >
$(LINUX_DIR)/.vermagic
So if I enable or disable any kernel built-in function (the "y" part),
this breaks compatibility with new modules. Ok, this makes sense. But
also if I disable or enable any modules ("m" part), this breaks
compatibility. Does this make sense? If I disable or enable a module,
any new modules should still be compatible with the kernel core,
right?
The Linux module system already has mechanims to prevent insertion of
incompatible modules into a running system. On my desktop, I see this:
$ modinfo video
[...]
vermagic: 3.8.0-33-generic SMP mod_unload modversions
The kernel blocks inserting a module where this vermagic doesn't match
[2]. (this is a different concept from OpenWrt's vermagic)
There is simply the set of symbols exported from the kernel - if a
module needs a symbol that is not available, it will not load. But
this is a pretty weak mechanisms as it does not detect other ABI
changes (struct layouts etc).
There is CONFIG_MODVERSIONS, which fingerprints ABI of each symbol
using CRC(full prototype) [3]. I am not familiar with the
implementation, but the documentation suggests it might be useful.
This is enabled on my desktop and appears to be a mature feature. I'm
not sure if this needs arch-level support - hopefully not and it's
just a matter of setting CONFIG_MODVERSIONS=y.
Could OpenWrt rely a bit more on the kernel's protections, to give
more flexibility in enabling modules after the first build?
I can spend some time on patches for this, but I wanted to open the
discussion first to understand the problem more broadly.
Catalin
[1] https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk#L108
[2] http://lxr.linux.no/linux+v3.12.1/kernel/module.c#L2719
[3] http://lxr.linux.no/linux+v3.12.1/Documentation/kbuild/modules.txt#L426
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
