[Gluster-devel] Integrating liburcu source into the glusterfs source tree
kshlmster at gmail.com
Mon Feb 2 03:40:36 UTC 2015
Thanks for this information Kaleb.
I'll check the changes I've done till now with the older versions of the
libraries. I think I'm going to need at least the 0.8.* release of liburcu,
as some new apis were introduced in it, which I'm using. I'll post the
outcome of my tests back here.
For a start, I collected the various versions of liburcu (userspace-rcu in
some) available in the different distros. This list is based on the distros
for which we provide community built packages and test on.
- Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages)
- Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages)
- EL7 - 0.7.9
- EL6 - 0.7.7
- Debian Wheezy - 0.6.7
- Debian Jessie - 0.8.5 (in testing)
- Ubuntu Precise - 0.6.7
- Ubuntu Trusty - 0.7.12
- Ubuntu Utopic - 0.8.4
- Netbsd - 0.8.6
- Freebsd - 0.7.7
The list doesn't look too good.
On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY <kkeithle at redhat.com> wrote:
> Just FYI, what you propose is called bundling in Fedora packaging
> parlance, and Fedora's packaging guidelines forbid bundling. It is possible
> to get an exception granted, but it's not safe to presume that an exception
> will be granted.
> (For downstream this is a non-issue, but here on gluster-devel we're not
> concerned with downstream.)
> You either need to convince the maintainers of liburcu to update to the
> newer versions everywhere, or you need to implement using the oldest
> version on the platforms you intend to support. And if this is too onerous,
> e.g. to use what's in (RH)EL5, then it's another argument in favor of
> dropping support for (RH)EL5. (The other argument is that python on RHEL5
> is too old for geo-rep.)
> In short, those of use who package gluster in Fedora would be, however
> reluctantly, required to vote against doing this. I recommend contacting
> the liburcu maintainers in Fedora/EPEL and see if you can't convince them
> to update to the newest version.
> /30/2015 12:09 PM, Deepak Shetty wrote:
>> On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M <kshlmster at gmail.com
>> <mailto:kshlmster at gmail.com>> wrote:
>> Hi all,
>> I had started a thread previously on the efforts we are undertaking
>> to improve thread synchronization in GlusterD . I had mentioned
>> that we will be using RCU for synchronization and the userspace RCU
>> library (liburcu)  for implementation.
>> I am now in a almost in a position to submit changes to Gerrit for
>> review. But, I have an obstacle of making liburcu available on the
>> jenkins slaves.
>> I have begun development using the 0.8.6 version of liburcu, which
>> is the latest stable release. EPEL has liburcu packages for CentOS 6
>> and 7, but they are the of the older 0.7.* versions. Fedora has
>> packages more recent packages, but they are still older, 0.8.1. .
>> Considering the above situation with binary packages, I'm
>> considering adding liburcu into the GlusterFS tree as a part of
>> /contrib. This will be similar in vein to the argp-standalone library.
>> liburcu is licensed under LGPL-v2.1, so I don't think there is going
>> to be any problem including it. But IANAL, so I would like to know
>> of if this would if this is okay from a legal perspective.
>> I'll add the liburcu source to our tree and push the change for
>> review. I'm not really familiar with autotools, so I'll need some
>> help integrating it into our build system. I'll update the list when
>> I have pushed the change for review.
>> How do you intend to add, as a git submodule or ?
>> I had worked on GNU autotools in the past, but frankly don't remember
>> much of it. If any help is needed I can try, or can get someone to help
>> from my ex-company :)
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel