|
From: | Amar Tumballi |
Subject: | Re: [Gluster-devel] Stable numbering of RPC procedures |
Date: | Tue, 18 Jun 2013 06:30:47 +0530 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 |
On 06/17/2013 02:39 PM, Niels de Vos wrote:
On Fri, Jun 14, 2013 at 12:07:51PM -0700, Anand Avati wrote:On Fri, Jun 14, 2013 at 1:40 AM, Bharata B Rao <address@hidden>wrote:On Mon, Jun 3, 2013 at 9:12 PM, Anand Avati <address@hidden> wrote:This looks more like a compile time feature check than runtime. The PKG_CONFIG() api number which had the initial set of QEMU requirementswas 3(i.e, PKG_CONFIG(..,glusterfs-api>=3,..). The new updates for Samba requirements has api number 4. Depending on whether discard supportmakes itbefore the next release (and api numbers gets published) or not, glfs_discard() would either be available in 4 or 5. Also, you might also want to add a second AC_CHECK_FUNC macro in configure.ac to be doublysure. Now with fallocate and discard support upstream, are you planning to increment the glusterfs-api version ? I still see the version as 4 in the git master. I need to decide if I should use version 4 or 5 to determine the availability of discard support from QEMU.This is yet to be determined. The fallocate/discard introduces change in the internal protocol/rpc and we're figuring out the right time to bring this patch into a release branch. Since release-3.4 is still "unreleased" there is a possibility, but we have not yet decided on it.I've just looked at the latest additions to the protocol/rpc procedures. If these changes have not made it to a release, please consider including this change first: - http://review.gluster.org/5215 Currently posted as RFC, no Bug yet. Let me know if this change is still possible, and I'll file a Bug and repost. I'll await your response before sending patches to the Wireshark project. (I need to know that the number of the new RPC procedures is stable.)
I looked at initial patch and the new one. Adding it to the end of the procedure list is surely better than adding them at the middle. But, in long run, its not good to make changes to existing version number itself. Any new changes to released RPC program spec should happen with bump in program version number.
-Amar
[Prev in Thread] | Current Thread | [Next in Thread] |