Hacking modversions

[Mike Hearn]

On Tue, 01 Mar 2005 21:13:46 +0100, Arjan van de Ven wrote:
> only if it's defined. the linux kernel internals aren't.

I'm using ABI to mean things that a recompile would fix. So I think that
is well defined (struct size changes, #define constant changes etc). 
 
> that by far isn't enough to describe the ABI. You also have to include
> things like locking order, locking rules and every other kind of
> behavior as well.
> Simple example: a function that suddenly no longer accepts NULL as a
> safe parameter but oopses. Ok artiticial, but not that much (esp if it
> was never supposed to be called with NULL) and it's REALLY hard to catch
> such ABI changes.

That's not (IMHO) an ABI change, that's a semantic change that recompiling
a module wouldn't fix anyway. So it's out of scope of what I was proposing.

>> It should be possible
>> to look at a bugfix and say "Yep that doesn't change the ABI".
> 
> you would be surprised how incredibly hard that is. Red Hat tries it
> really hard for RHEL, and even there we accidentally break the ABI like
> every other update release in practice, despite trying REALLY hard.

I'm thinking for things like, "XYZ doesn't validate parameters" or "race
condition in function ABC". For more extensive changes yes, I know it's
hard.
 
> It simply isn't as simple as it sounds. Most security fixes nowadays are
> either very local, or cross multiple functions, probably in a 50% ratio
> each. The moment you cross a function barrier you've lost in the "easy
> ABI" game and it gets REALLY tricky. And even for local fixes it's not
> always so easy... take the NULL pointer example.

I think we're using different terminology - I'd refer to breaking changes
in the behaviour of a function not as ABI but as semantics. ABI would
be about linkage, and so on.

thanks -mike