Quote:
Originally Posted by NullNix
static const char __mod_vermagic5[] __attribute__((__used__)) __attribute__((section(".modinfo"),unused)) = "vermagic" "=" "2.6.26.8-rt16-lab126" " " "" "" "mod_unload " "modversions " "ARMv" "6" " ";
means
"An initialized constant char array variable named __mod_vermagic5, symbol named "vermagic", in the .modinfo section, included even if unused, we declare that it is used even if it doesn't seem to be, contents "2.6.26.8-rt16-lab126mod_unloadmodversionsARMv6 "."
The significance of that content is that it includes, uh, not everything, but *most* things that might make this kernel ABI-incompatible with other kernels, so that you can compare the contents of this section in a module with the content of the same in the kernel to see if they might be compatible.
This is very definitely a kludge: lots of things can cause ABI incompatibilities which are not included in that string, but everything in the string is relatively certain to, except perhaps minor changes to the version number (but there's no way to tell if a core kernel change didn't change some structure somewhere, so best to rule such changes out too).
|
The point is, those empty fields.
That is the list of symbol signatures and symbol version ID that is missing in the expansion.
The kernel will not load a module unless the symbol signatures and version ID of each symbol match what it provides (which is why you shouldn't strip the symbol table off of the kernel binary).
But the other point made is also valid -
Just because the external code interfaces correctly (by the above tests) to provide a "wash foobar" function does not mean that the code actually washes foobars. It might churn butter instead.