[oe] [RFC] Rebuild external kernel modules on kernel change

Phil Blundell philb at gnu.org
Mon Jun 1 20:17:06 UTC 2009


On Mon, 2009-06-01 at 19:25 +0200, Koen Kooi wrote:
> 2) is *very* hard to track down, e.g. people don't expect that enabling 
> netfilter as modules breaks external wifi drivers since struct sk_buff 
> will change (ask nokia 770 tablet users).
> I bet there are a lot more cases where kernel runtime abi changes, so 
> every kernel PR bump will trigger a rebuild *and* (here's comes the most 
> important bit) an automatic PR bump for recipes using module*.bbclass.

The networking code is indeed particularly bad in that respect.  But in
general Tom is right, the vast majority of kernel config changes
(enabling drivers, adjusting command line parameters or default
settings, that kind of thing) don't have ABI impact and there is no need
to rebuild everything as a result.

The easiest way to deal with that issue is probably to have a separate
KERNEL_PACKAGE_ABIVERSION variable which is set locally in the kernel's
own .bb file, which is appended to the regular kernel-abiversion, and
which you can manually increment when making a change that causes, or is
likely to cause, an ABI change.  If you, as a kernel package maintainer,
want to take a particularly conservative line with your own kernels then
you can simply set KERNEL_PACKAGE_ABIVERSION = "${PR}" and it will act
as you describe above; other maintainers who want to avoid unnecessary
rebuilds can use their own judgement about when to increment it.  

For folks who use MODVERSIONS, it'd probably be easy enough to add an
extra check to detect when the symbol hashes have changed since the last
build and emit an error.  In an ideal world, you'd even be able to
generate a single ABI footprint by, say, taking a sha256 hash of the
catenation of all the symbol versions.  Then, your kernel package could
Provide: kernel-abi-123456abc, all your module packages could Depend: on
the same thing, and (modulo a little bit of package manager tweaking
along roughly the same lines as we use for locales) everything would
"just work".

p.






More information about the Openembedded-devel mailing list