ABI vs. API (Re: [kerberos-discuss] thoughts/issues making MIT krb code fit for drop-in to Solaris)

Nicolas Williams Nicolas.Williams at sun.com
Fri Sep 19 13:03:03 EDT 2008

On Fri, Sep 19, 2008 at 12:39:41PM -0400, Simo Sorce wrote:
> Both API and ABI compatibility are important.


> API compatibility is more important for developers.

I don't quite agree.  Developers who distribute binaries want their
binaries to run.  They also want their code to remain buildable.  See

> ABI compatibility is more important for system administrators.

And users, and developers.  See above.

Also, in practice ABI compatibility makes API compatibility very likely,
with at most minor source changes needed if the API is changed
incompatibly.  Changing, e.g., a typedef *may* be source-incompatible,
but binary compatible.

Whereas focusing on API compatibility alone often leads to ABI
incompatibilities.  E.g., changing a struct size/layout -> API
compatible (sources rebuild), ABI incompatible (assuming the
struct's size/layout is part of the ABI).

We (Sun) are more cavalier (though far from careless) about API
compatibility than ABI.  Our compatibility guarantee is, after all, a
*binary* compatibility guarantee.  If your vendor/distro maintainer
doesn't do the same for you, forcing you to rebuild everything
periodically, then you're likely to care about source compatibility a
lot more.

> THe important thing is to reach a decent balance and make sure ABI/API
> breaks happen on a major release and they are very well advertized in
> advance, so that vendors can plan how to address the issue.

The MIT krb5 has not had a well-defined API.  Therefore MIT has focused
on ABI compatibility: if something breaks binary compatibility, they'll
fix it.

In fact, though the Consortium appears to be making progress w.r.t. API
documentation, until the API is fully documented then the Consortium has
no choice but to focus on ABI compatibility.


More information about the krbdev mailing list