[lug] Kernel Module Compile Config Q

[Lee Woodworth]

I can think of two ways such a change could be a problem:

1) If the kernel module has any hard references to static
   addresses in the kernel (not symbolic). The new configuration
   will cause some addresses to change. Things like non-exported
   kernel functions would be possibilities.

2) If the new configuration changed the layout/size of any
   kernel data structures. New module with the new size/layout
   using the old kernel's structures.

On 06/27/2014 05:33 PM, stimits at comcast.net wrote:
> Hi,
> .
> I'm wondering about a module compile for network bridging (3.10 kernel) which results in a kernel panic. I'm thinking the panic is because of a config change dependency which might demand rebuilding the whole kernel. I want to know if this dependency and sticking to only module compiles without a new kernel compile would be the cause. Can I get away without rebuilding and installing a new kernel?
> .
> This is the running kernel source tree and entirely configured based on current running system (I have the config in /boot option), with proper preparation before compile (compile itself is on the native system). Then I add bridge support as a module (via make menuconfig). Intentionally building CONFIG_BRIDGE=m results in a couple of other dependencies which builds modules that insmod without error, but one non-optional dependency is CONFIG_BRIDGE_NETFILTER=Y, so I cannot insmod this. With module dependencies loaded via insmod, I then insmod bridge.ko...kernel panic.
> .
> The dependency which is forced as a non-module is CONFIG_BRIDGE_NETFILTER=Y, and I'm guessing this is why I won't be able to stick to a pure module build. In general, if I build something as a module, and if that module forces some other CONFIG_WHATEVER=Y, is this always asking for trouble? I'd really like to stick to not flashing the kernel image itself on this embedded system.
> 
> 
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>