[OpenAFS-devel] kabi-tracking kmods

[Jason Edgecombe]

On 09/27/2012 10:05 AM, Troy Benjegerdes wrote:
> 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.
I can't speak for the original poster, but I'm stuck with RHEL at my 
site. I'm in the IT group for an engineering college at a university. 
Our vendor-provided apps aren't supported on debian/ubuntu, only RHEL/SuSE.

Jason