Re: Stable numbering of RPC procedures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <bharata.rao@xxxxxxxxx>wrote:

On Mon, Jun 3, 2013 at 9:12 PM, Anand Avati <anand.avati@xxxxxxxxx> wrote:
This looks more like a compile time feature check than runtime. The
PKG_CONFIG() api number which had the initial set of QEMU requirements
was 3
(i.e, PKG_CONFIG(..,glusterfs-api>=3,..). The new updates for Samba
requirements has api number 4. Depending on whether discard support
makes it
before 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 doubly
sure.

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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux