[OpenAFS] Re: Red Hat RPM packaging

[Jon Stanley]

On Mon, Sep 15, 2014 at 10:28 PM, Jeffrey Altman
<jaltman@your-file-system.com> wrote:

> 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
think:

$ ./rhel6_kabi_check.py -w
/lib/modules/kabi-current/kabi_whitelist_x86_64
lib/modules/2.6.32-431.29.2.el6.x86_64/extra/openafs/openafs.ko
Red Hat Enterprise Linux 6 ABI Checker
--------------------------------------

ABI Checker version: 2.0

Module:    lib/modules/2.6.32-431.29.2.el6.x86_64/extra/openafs/openafs.ko
Kernel:    2.6.32-431.29.2.el6.x86_64
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.

symbol: posix_test_lock
symbol: page_put_link
symbol: key_alloc
symbol: generic_file_splice_read
symbol: bdi_register
symbol: bdi_destroy
symbol: unregister_key_type
symbol: generic_file_splice_write
symbol: posix_lock_file
symbol: key_type_keyring
symbol: groups_alloc
symbol: key_instantiate_and_link
symbol: register_key_type
symbol: __put_cred
symbol: force_sig
symbol: mntput_no_expire
symbol: copy_page
symbol: page_follow_link_light
symbol: key_put
symbol: prepare_creds
symbol: __splice_from_pipe
symbol: dcache_lock
symbol: __page_cache_alloc
symbol: bdi_init
symbol: d_move
symbol: page_readlink
symbol: key_validate
symbol: splice_direct_to_actor
symbol: flock_lock_file_wait
symbol: keyring_search
symbol: names_cachep
symbol: groups_free
symbol: commit_creds
symbol: simple_sync_file
symbol: do_settimeofday
symbol: d_path

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
http://people.redhat.com/jcm/el6/dup/docs/scripts/rhel6_kabi_check.py

> 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 :)