[OpenAFS] Re: Red Hat RPM packaging
Mon, 15 Sep 2014 22:57:26 -0400
On Mon, Sep 15, 2014 at 10:28 PM, Jeffrey Altman
> Do you consider the use of non-kabi symbols by OpenAFS to be a bug in
> OpenAFS or the Linux kernel?
OpenAFS. Third party modules that expect compatibility between RHEL
releases must not use kernel symbols that aren't on the kABI whitelist
provided by Red Hat. Note that this is a vendor-specific construct -
RH has made guarantees that they will not touch the ABI of symbols on
the whitelist in the lifetime of that minor release of RHEL (i,e,
RHEL6,5). However, in most cases, the ABI isn't touched even between
minor releases, and more stability is added. Looking back through
history between RHEL6.0 and 6.5, 33 symbols have been dropped from the
whitelist (mostly related to wireless driver interfaces) and 314
symbols have been added.
> 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*.
Actually commercial filesystems like VxFS adhere to the whitelist (I
think, it's been forever since I touched VxFS on Linux - or Solaris
for that matter :D), so it's definitely possible to do. I'm at home
right now, so I didn't have a built AFS close by to look at, but I
built it on a quick VM and the situation isn't quite as bad as you
$ ./rhel6_kabi_check.py -w
Red Hat Enterprise Linux 6 ABI Checker
ABI Checker version: 2.0
Whitelist: /lib/modules/kabi-current/kabi_whitelist_x86_64 (package
kabi-whitelists is not installed
WARNING: The following symbols are used by your module
WARNING: and are not on the ABI whitelist.
Just getting rid of the usage of these symbols from OpenAFS would go a
long ways to ensure compatibility within and between RHEL releases.
The script can be found at
> 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.
Cool, but would it be easy for an OpenAFS user to migrate to these,
and is the in-kernel AFS nearly as complete as OpenAFS? My immediate
guess would be no on both counts, but I'd love to hear otherwise :)