[OpenAFS-devel] question: binary interface to kernel module (RHEL6.2/6.3, openafs 1.6.1)?

Simon Wilkinson simonxwilkinson@gmail.com
Thu, 30 Aug 2012 21:34:59 +0100


On 30 Aug 2012, at 14:56, Stephan Wiesand wrote:
>=20
> That was obviously true for EL5, where I never would have considered =
this approach. But as of EL6, the list of ABI hashes published and =
checked includes the ones that aren't on the whitelist, and is supposed =
to be complete. And none of those interfaces used by the openafs module =
changed.

Yeah, sorry, I was thinking about the EL5 world. However, there are =
still issues with doing what you're proposing on EL6.

These ABI hashes are automatically generated (they're actually a way of =
exposing the kernel's modversion values to RPM). As you note, in EL6 =
they encapsulate the function parameters and return type of each =
exported function in the kernel. If the parameters or type changes, the =
signature will change, and modprobe will block loading the module.

However, as autogenerated values there are nuances that they can't =
capture. For instance, if the usage of a particular function changes so =
that you have to acquire a lock before calling it. Or, if an existing =
"flag" parameter gains a value that tells you that the function is being =
called under the RCU lock, and requires you to take preventative action.

As far as I can tell, they also have no way of communicating disconnects =
between functions that are split between a 'static inline' function in a =
kernel's header files, and 'normal' functions in the object code of the =
kernel. If code is moved between the inline function, and the normal =
function between kernel revisions, that move won't change the interface =
hash, but you'll end up not doing things, or doing things twice, because =
the inline function you're using doesn't match the 'normal' function =
that you've linked against.

This is why the kABI stuff is invaluable - for that set of functions, =
RedHat make sure that those kind of mixups can't happen. For everything =
else, there are no guarantees.

Cheers,

Simon.