Re: rdma-core 12 breaks libibverbs ABI

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Thu, Jan 26, 2017 at 08:38:40PM +0000, Hefty, Sean wrote:
> > > There should not be any compat - it's just going to drag down
> > > development and everyone is free to submit their provider to rdma-
> > core,
> > > same as kernel drivers.
> > 
> > Yep, that was the argument that won the day so far.
> 
> I don't disagree with the direction, but I agree with Benjamin.  The
> intent behind a public symbol/structure and their actual usage by
> applications may differ.  Why wasn't the soname updated?

Well, no it cannot differ. If apps use private symbols they get
burned. Glibc and gcc have established that precedent decades ago.

The soname is not bumped because libibverbs is a symver based library,
which means we can manage our private ABI safely without ever
requiring soname changes. If something does manage to link to it then
it gets a runtime dynamic linking failure, not a random crash.

Remember, libibverbs fundamentally does not support two copies of the
library in the same address space, so one of the major motivations to
use a soname to manage version is invalid. Even worse, because of
this, if we did bump the soname, it would be very painful and
dangerous.

So that leaves us with only one point to argue on: Should libibverbs
have a private ABI or not? If yes, then we are doing it properly.

The issue is muddied a bit because the private ABI has not been as
absolutely private as I'd like, so we could add compat for the two
symbols and defer the incompat transition till a later release.. This
argument would be best supported if someone knows of something that
actually breaks out in the wild...

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html