On 9/15/2014 10:12 PM, Jon Stanley wrote: > On Mon, Sep 15, 2014 at 4:45 PM, Andrew Deason <[email protected]> wrote: >> Specifically by "not work", I mean, we've had a kernel receive a minor >> update that was supposed to not break kabi compatibility, but it broke >> us, and it was fixed by just building against a newer kernel. But as I > > Do you use symbols only on the kabi whitelist? If not, compatibility > is not guaranteed. If so, then that's a bug that you should complain > (loudly) about.
Do you consider the use of non-kabi symbols by OpenAFS to be a bug in OpenAFS or the Linux kernel? If the Linux kernel, to whom should a complaint be filed? As a file system OpenAFS touches many symbols that are not on the kabi whitelist. There are somewhere between 60 and 150 symbols used by OpenAFS that are not. The advice that has been provided in the past is to become part of the kernel distribution so that the code tracks the unstable interfaces with each release. However, that is not possible due to the IBM Public License 1.0 being incompatible with GPL*. David Howell's has an in-kernel AFS kernel module but its behavior is sufficiently different from the OpenAFS kernel module as to be disruptive for end users. There were efforts to modify David's kmod to share the OpenAFS userland tools but those ran into insurmountable hurdles. I believe David is now in the process of writing his own userland tool chain. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
