All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niels de Vos <ndevos@redhat.com>
To: Jeff Cody <jcody@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] block/gluster: Handle changed glfs_ftruncate signature
Date: Sat, 28 Jul 2018 09:50:05 +0200	[thread overview]
Message-ID: <20180728075005.GE1827@ndevos-x270> (raw)
In-Reply-To: <20180728041839.GA1325070@localhost.localdomain>

On Sat, Jul 28, 2018 at 12:18:39AM -0400, Jeff Cody wrote:
> On Fri, Jul 27, 2018 at 08:24:05AM -0500, Eric Blake wrote:
> > On 07/27/2018 03:19 AM, Niels de Vos wrote:
> > >From: Prasanna Kumar Kalever <prasanna.kalever@redhat.com>
> > >
> > >New versions of Glusters libgfapi.so have an updated glfs_ftruncate()
> > >function that returns additional 'struct stat' structures to enable
> > >advanced caching of attributes. This is useful for file servers, not so
> > >much for QEMU. Nevertheless, the API has changed and needs to be
> > >adopted.
> > >
> > 
> > Oh, one other comment.
> > 
> > >+++ b/block/gluster.c
> > >@@ -20,6 +20,10 @@
> > >  #include "qemu/option.h"
> > >  #include "qemu/cutils.h"
> > >+#ifdef CONFIG_GLUSTERFS_LEGACY_FTRUNCATE
> > >+# define glfs_ftruncate(fd, offset, _u1, _u2) glfs_ftruncate(fd, offset)
> > >+#endif
> > 
> > Someday, when we can assume new enough gluster everywhere, we can drop this
> > hunk...
> > 
> 
> 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.

> > >+++ b/configure
> > 
> > >+	/* new glfs_ftruncate() passes two additional args */
> > >+	return glfs_ftruncate(NULL, 0 /*, NULL, NULL */);
> > >+}
> > >+EOF
> > >+    if compile_prog "$glusterfs_cflags" "$glusterfs_libs" ; then
> > >+      glusterfs_legacy_ftruncate="yes"
> > >+    fi
> > 
> > ...but it will be easier to remember to do so if this comment in configure
> > calls out the upstream gluster version that no longer requires the legacy
> > workaround, as our hint for when...
> > 
> 
> 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.

Thanks for correcting the last bits of the patch!
Niels


> > >    else
> > >      if test "$glusterfs" = "yes" ; then
> > >        feature_not_found "GlusterFS backend support" \
> > >@@ -6644,6 +6658,10 @@ if test "$glusterfs_zerofill" = "yes" ; then
> > >    echo "CONFIG_GLUSTERFS_ZEROFILL=y" >> $config_host_mak
> > >  fi
> > >+if test "$glusterfs_legacy_ftruncate" = "yes" ; then
> > >+  echo "CONFIG_GLUSTERFS_LEGACY_FTRUNCATE=y" >> $config_host_mak
> > 
> > ...this #define is no longer necessary.
> > 
> > -- 
> > Eric Blake, Principal Software Engineer
> > Red Hat, Inc.           +1-919-301-3266
> > Virtualization:  qemu.org | libvirt.org

  reply	other threads:[~2018-07-28  7:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-27  8:19 [Qemu-devel] [PATCH v3] block/gluster: Handle changed glfs_ftruncate signature Niels de Vos
2018-07-27 13:21 ` [Qemu-devel] [PATCH v3 for-3.0] " Eric Blake
2018-07-27 13:24 ` [Qemu-devel] [PATCH v3] " Eric Blake
2018-07-28  4:18   ` Jeff Cody
2018-07-28  7:50     ` Niels de Vos [this message]
2018-07-30 15:07       ` Eric Blake
2018-07-30 19:27         ` Jeff Cody
2018-07-31  9:18           ` Niels de Vos
2018-07-31 19:51             ` Jeff Cody
2018-08-01 11:47               ` Niels de Vos
2018-08-01 15:17                 ` Eric Blake
2018-07-30 21:24       ` Jeff Cody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180728075005.GE1827@ndevos-x270 \
    --to=ndevos@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=prasanna.kalever@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.