On Wed, Sep 26, 2012 at 3:33 PM, Stephan Wiesand <[email protected]> wrote: > On Sep 26, 2012, at 00:09 , Ken Dreyer wrote: >> My small experience with kabi kmod packages is limited to ATI's video >> drivers and OpenAFS. It has worked sometimes, but other times I've had >> to rebuild against RHEL 6's newer kernels in order to get a module to >> work properly. I'm wondering what's the best direction overall. > > To my understanding: Unless a module uses whitelisted symbols only, > kabi-tracking kmod's aren't safe across minor EL6 releases, at least. > They may be safe within minor releases. Alas, the current way of > packaging does not even support that kind of use at all: There's no > way to have more than one module installed at a time, and the single > module will be made available to kernels in which it may render the > system completely unusable, or cause any other kind of problems. As > Simon pointed out, this could well affect data integrity, making the > issue really serious in the openafs case. Taking the risk may be ok > for a display driver. For a filesystem, it probably isn't.
Thank you, that helps me understand. So what will your approach be in Scientific Linux for this? Also, I guess ELRepo will suffer the same problem? RPM Fusion is looking at using kabi-tracking for kmods for EL, which is why I'm interested. - Ken _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
