Would it be possible to use ELF symbol versioning to bump the versions of all affected functions without bumping the .so number? That would provide an upgrade path for distros. The downside is that the new librados would need to keep compat shims for old clients. On Thu, Oct 19, 2017 at 6:13 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: > On Thu, 19 Oct 2017, Jason Dillaman wrote: >> As long as we plan to continue to ship librados2 side-by-side with >> librados3 for a while, I'm fine with starting down that path for >> mimic. There are a lot of applications linked against librados2 >> floating in the wild. >> >> For luminous, we could perhaps just drop the "_mempool" member >> variable from bufferlist and chance the semantics where the caller >> needs to add at least a single buffer::raw before the mempool can be >> assigned. That preserves the ABI since we aren't changing the size of >> bufferlist and preserves the mempool functionality (with a little >> extra work). That tweak would only be needed for the first >> buffer::ptr appended to the bufferlist since subsequent appends can >> just copy the mempool value from the first buffer::ptr. > > I think that will still be sufficient for bluestore (which relies on > mempool accounting to make its cache trimming work). I can give it a try > today! > > sage > >> On Thu, Oct 19, 2017 at 6:43 AM, John Spray <jspray@xxxxxxxxxx> wrote: >> > On Thu, Oct 19, 2017 at 10:25 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: >> >> in luminous, we introduced a change not backward compatible with >> >> pre-luminous librados. see see http://tracker.ceph.com/issues/21573. >> >> and i cannot see an obvious solution without bumping up the so version >> >> of librados to 3. >> >> >> >> if we have the luxury to do it, we will be able to give librados an >> >> overhaul. for a todo list, see http://pad.ceph.com/p/librados3. >> >> >> >> what do you think? >> > >> > I've added a couple of items to the pad for deprecated bits to remove >> > when we go up a version. >> > >> > I guess we would do the version bump for Mimic and for Luminous we >> > will just have to apologetically tell people they need to recompile? >> > >> > Or we could have a so.3 version (ABI change only) in Luminous that >> > just bumps the version to force a recompile, and a so.4 version in >> > Mimic that actually makes the API changes? >> > >> > John >> > >> >> >> >> -- >> >> Regards >> >> Kefu Chai >> >> -- >> >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> -- >> Jason >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
