[OpenAFS-devel] Re: kabi-tracking kmods

[Troy Benjegerdes]

Based on my understanding, this is a business strategy of Red Hat
to get big customers, and third-party non-GPL software vendors to
get them to sign big money service and support contracts for RHEL.

OpenAFS falls into the 'third party non-GPL software' category.

It's completely clear to me why it doesn't work... that's because
subtle breakage of the 'stable' interface by anything linking into
the linux kernel is in the best interest of everyone who is employed
by Red Hat writing and patching the kernel. Red Hat employees will
say they are 'committed to providing stable interfaces' publicly,
and what you'll see in practice is something else entirely.  

Kind of like the commitments I keep hearing about people make on 
this mailing list.

We can either keep recompiling, pay big money, or use the Red Hat 
developed kAFS.

On Wed, Sep 26, 2012 at 01:45:44PM -0500, Andrew Deason wrote:
> On Wed, 26 Sep 2012 11:38:31 -0500
> Troy Benjegerdes <hozer@hozed.org> wrote:
> 
> > 2) RHEL defines which kabi functions are 'stable'
> 
> I'm not sure if you understand what Ken is talking about. As far as I
> can tell, Red Hat's intent is that this is supposed to still work even
> for things that do not stick to any "stable" whitelist of functions (for
> RHEL6 and beyond). So if something not "stable" changes, the kernel will
> recognize that the relevant kernel module is not compatible, and you
> need to recompile the thing. So we're not supposed to need to stick to a
> stable ABI.
> 
> But as the thread that Ken linked shows, it doesn't seem to work.  We're
> not sure why it doesn't work for that particular case, and Red Hat's new
> kernel patching policies make it difficult to figure out. I think it's
> hard to say how often that will reoccur without knowing what actually
> broke.
> 
> It's of course safer to just recompile for any version change, but if
> that were acceptable to everyone I expect this kabi stuff wouldn't exist
> in the first place. I personally don't find it "worth it" to try and
> figure this out at the moment, but I've treated Linux's lack of
> interface stability/design as something to just 'live with' for awhile,
> so it doesn't bother me so much.
> 
> -- 
> Andrew Deason
> adeason@sinenomine.net
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel