On Mon, Jan 30, 2017 at 10:03:41AM -0700, Jason Gunthorpe wrote: > On Mon, Jan 30, 2017 at 03:59:59PM +0200, Leon Romanovsky wrote: > > On Thu, Jan 26, 2017 at 04:08:13PM -0700, Jason Gunthorpe wrote: > > > The first part is to remove the header files that define the > > > prototypes for these symbols from the set of packaged headers. > > > This ensures that nothing can compile and use these symbols. > > > > > > Next we move the symbols into a new symbol version stanza only > > > for the private ABI. This breaks every existing out of-tree provider, > > > but the earlier change to ibv_cmd_create_ah already did that. > > > > > > There are a few symbols that are still private by virtue of not being > > > in public headers, but these are used internally by the other libraries. > > > For distribution sanity continue to treat them as public ABI. > > > > > > Signed-off-by: Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> > > > Documentation/versioning.md | 22 ++++++++ > > > debian/control | 2 +- > > > debian/libibverbs-dev.install | 3 -- > > > debian/libibverbs1.symbols | 44 +-------------- > > > libibverbs/CMakeLists.txt | 9 ++-- > > > libibverbs/libibverbs.map | 122 +++++++++++++++++++++--------------------- > > > 6 files changed, 93 insertions(+), 109 deletions(-) > > > > How is it connected to ABI soname versioning? > > https://github.com/linux-rdma/rdma-core/blob/master/Documentation/versioning.md > > Not sure I follow.. > > Those guidelines continue to apply to the public symbols. > > > libibverbs.map's ABI version was 1.4 before and it was synced with > > CmakeList, but now, it won't. > > The map file will have two sections now, one for public symbols that > will continue to use the 1.3/1.4/etc system But you removed IBVERBS_1.4. Do we introduce IBVERBS_1.4 again? > (Ah, Yishai forgot to update CMakeLists when he added the 1.4 symbols, Yeah, I spotted it too while reviewed your patch and worked on direct verbs improvements. > oops, we need a travis check for this I guess..) > > The other is the private symbol section that basically just tracks the > release number. There will only ever be one PRIVATE section since we > don't provide compat. We do not attempt to reflect the PRIVATE symbols > in the filename. I understand rationale behind this and agree with you regarding the change. > > The file name will continue to be 1.3.${PACKAGE_VERSION} but it is > largely irrelevant.. It is better to keep in sync these numbers in CmakeLists and map file. > > Jason
Attachment:
signature.asc
Description: PGP signature
