On 30 Aug 2012, at 14:56, Stephan Wiesand wrote: > > 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
