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
