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
