On Tue, 30 Sep 2014 23:52:19 +0100 Ned Slider ned@unixmail.co.uk wrote:
On 30/09/14 22:57, ross smith wrote:
On Tue, Sep 30, 2014 at 4:41 PM, Andrew Deason adeason@sinenomine.net wrote:
That sounds good, but do we know how the kmod builds are going to work at all?
RHEL (and hence CentOS) has contained the framework to solve that particular problem since el5. It's part of the Driver Update Program (DUP) which allows 3rd party kABI-compatible kmod packages to be built against one kernel and work seamlessly with all kABI-compatible kernels.
The openafs kernel module uses symbols outside of the kABI whitelist out of necessity [1], and has been proven to break previously on kernel updates that trusted the DUP.
So, we try to disable and avoid any mechanisms involving the kABI/DUP stuff as much as possible. If it is not possible to build against every kernel in CentOS's buildsystem, that's not a showstopper, since 'most' users would be happy with DKMS, and the rest can find their own way to develop their own kmods or get them from somewhere else. But I'm just always inquiring if it's just possible to build for every kernel, since that will work for everyone. (And it's what upstream does now, and what someone will have to do anyway.)
[1] While I have not actually spent any significant time trying to avoid the 'bad' symbols, the last list I saw for EL6 included some symbols that seemed pretty impractical: http://article.gmane.org/gmane.comp.file-systems.openafs.general/35234 (not all of them, but in particular some of the keyring and fs related ones). And even if it were possible, the effort required for doing so I think would make this impractical for the short term.