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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
