[OpenAFS-devel] kabi-tracking kmods

[Troy Benjegerdes]

On Wed, Sep 26, 2012 at 03:37:34PM -0600, Ken Dreyer wrote:
> On Wed, Sep 26, 2012 at 3:33 PM, Stephan Wiesand
> <stephan.wiesand@desy.de> 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

This may be a loaded question, but I'll ask it anyway.. With all these
packaging problems with Red Hat, would it be possible to switch to 
Debian? The kernel packaging seems a lot more sane.

If Red Hat is a requirement, then what are the perceived obstacles to
making the in-kernel kafs module do all the filesystem stuff, and all 
OpenAFS packages need to do is provide userspace tools?

Both fuse and arla (mentioned elsewhere) would also solve the problem,
but you are going to wind up in context-switch hell going to the kernel
for a write, back to userspace through fuse/nnpfs, then back to the
kernel. It will probably work very reliably, but will either be slow 
or with a lot of cpu overhead.