From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fkQnG-0002I3-0L for qemu-devel@nongnu.org; Tue, 31 Jul 2018 05:18:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fkQnE-0006YD-W8 for qemu-devel@nongnu.org; Tue, 31 Jul 2018 05:18:14 -0400 Date: Tue, 31 Jul 2018 11:18:02 +0200 From: Niels de Vos Message-ID: <20180731091802.GL17519@ndevos-x270> References: <20180727081939.28185-1-ndevos@redhat.com> <20180728041839.GA1325070@localhost.localdomain> <20180728075005.GE1827@ndevos-x270> <2bf3b1f9-ab42-5256-8093-7c41aaa9f2d6@redhat.com> <20180730192729.GA443110@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180730192729.GA443110@localhost.localdomain> Subject: Re: [Qemu-devel] [PATCH v3] block/gluster: Handle changed glfs_ftruncate signature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: Eric Blake , qemu-block@nongnu.org, qemu-devel@nongnu.org, Prasanna Kumar Kalever On Mon, Jul 30, 2018 at 03:27:29PM -0400, Jeff Cody wrote: > On Mon, Jul 30, 2018 at 10:07:27AM -0500, Eric Blake wrote: > > On 07/28/2018 02:50 AM, Niels de Vos wrote: > > >> > > >>Part of me wishes that libgfapi had just created a new function > > >>'glfs_ftruncate2', so that existing users don't need to handle the api > > >>change. But I guess in the grand scheme, not a huge deal either way. > > > > > >Gluster uses versioned symbols, so older binaries will keep working with > > >new libraries. It is (hopefully) rare that existing symbols get updated. > > >We try to send patches for these kind of changes to the projects we know > > >well in advance, reducing the number of surprises. > > > > >>I can go ahead and add that to the comment in my branch after applying, if > > >>Niels can let me know what that version is/will be (if known). > > > > > >The new glfs_ftruncate() will be part of glusterfs-5 (planned for > > >October). We're changing the numbering scheme, it was expected to come > > >in glusterfs-4.2, but that is a version that never will be released. > > > > > > > Wait - so you're saying gluster has not yet released the incompatible > > change? Now would be the right time to get rid of the API breakage, before > > you bake it in, rather than relying solely on the versioned symbols to avoid > > an ABI breakage but forcing all clients to compensate to the API breakage. > > > > If this is not yet in a released version of Gluster, I'm not real eager to > pollute the QEMU driver codebase with #ifdef's, especially if there is a > possibility the API change may not actually materialize. > > Is there any reason that this change is being approached in a way that > breaks API usage, and is it too late in the Gluster development pipeline to > change that? There recently have been a few changes like this in libgfapi. These have been introduced to improve performance in common use-cases where an updated 'struct stat' is needed after an operation. Some functions have been adapted in previous releases, glfs_ftruncate() landed too late for that. I hope we'll get a complete coherent API with glusterfs-5 again. For QEMU this means additional changes will come related to glfs_fallocate(), glfs_zerofill() and probably more. The current glusterfs-4.1 version will be maintained for one year, after which the detection/#ifdef can be removed as the than maintained versions should all have the updated API. I'm sorry for the inconvenience that this causes. If you prefer, I can wait with sending patches for QEMU with future Gluster releases until additional changes have landed in libgfapi. Thanks, Niels