<div dir="ltr">I'm currently testing my changes with liburcu-0.7.* . It is missing just one API which I'm using from 0.8. I've written a local implementation of just that one function, and am currently in process of testing this. If this test is successful, then our problems will be minimized.<div><br></div><div>This only leaves out Debian Wheezy and Ubuntu Precise with liburcu-0.6.* . I tried testing this out, but as liburcu-0.6 doesn't apparently provide pkg-config configurations, I stopped as soon as I started.<div><br></div><div>~kaushal<br><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 2:37 PM, Niels de Vos <span dir="ltr"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Feb 02, 2015 at 09:10:36AM +0530, Kaushal M wrote:<br>
> Thanks for this information Kaleb.<br>
><br>
> I'll check the changes I've done till now with the older versions of the<br>
> libraries. I think I'm going to need at least the 0.8.* release of liburcu,<br>
> as some new apis were introduced in it, which I'm using. I'll post the<br>
> outcome of my tests back here.<br>
><br>
> For a start, I collected the various versions of liburcu (userspace-rcu in<br>
> some) available in the different distros. This list is based on the distros<br>
> for which we provide community built packages and test on.<br>
><br>
> - Fedora 21 - 0.8.1 (0.8.5 in testing but stuck due to some breakages)<br>
> - Fedora 20 - 0.7.7 (0.8.5 in testing but stuck due to some breakages)<br>
> - EL7 - 0.7.9<br>
> - EL6 - 0.7.7<br>
> - Debian Wheezy - 0.6.7<br>
> - Debian Jessie - 0.8.5 (in testing)<br>
> - Ubuntu Precise - 0.6.7<br>
> - Ubuntu Trusty - 0.7.12<br>
> - Ubuntu Utopic - 0.8.4<br>
> - Netbsd - 0.8.6<br>
> - Freebsd - 0.7.7<br>
><br>
> The list doesn't look too good.<br>
<br>
</span>I do not like including libraries in the glusterfs sources. Currently<br>
there are several bits under contrib/ that do not see any maintenance.<br>
Who will be maintaining (fixing potential bugs, backporting newer<br>
versions, ...) for linurcu? Note that we support *many* different<br>
distributions, architectures and master+3 releases.<br>
<br>
It would be *so* much more efficient to use the distributions version of<br>
liburcu. Maybe it is possible to write some wrapper functions for the<br>
older versions of the library, and place those wrappers in contrib/<br>
instead?<br>
<br>
Alternatively, we could maintain packages for liburcu in our<br>
repositories on <a href="http://download.gluster.org" target="_blank">download.gluster.org</a> for distributions that do not have<br>
a recent enough version. You will need to find a relyable packager that<br>
agrees to take on this task.<br>
<span class="HOEnZb"><font color="#888888"><br>
Niels<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> ~kaushal<br>
><br>
><br>
> On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY <<a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > Just FYI, what you propose is called bundling in Fedora packaging<br>
> > parlance, and Fedora's packaging guidelines forbid bundling. It is possible<br>
> > to get an exception granted, but it's not safe to presume that an exception<br>
> > will be granted.<br>
> ><br>
> > (For downstream this is a non-issue, but here on gluster-devel we're not<br>
> > concerned with downstream.)<br>
> ><br>
> > You either need to convince the maintainers of liburcu to update to the<br>
> > newer versions everywhere, or you need to implement using the oldest<br>
> > version on the platforms you intend to support. And if this is too onerous,<br>
> > e.g. to use what's in (RH)EL5, then it's another argument in favor of<br>
> > dropping support for (RH)EL5. (The other argument is that python on RHEL5<br>
> > is too old for geo-rep.)<br>
> ><br>
> > In short, those of use who package gluster in Fedora would be, however<br>
> > reluctantly, required to vote against doing this. I recommend contacting<br>
> > the liburcu maintainers in Fedora/EPEL and see if you can't convince them<br>
> > to update to the newest version.<br>
> ><br>
> > Regards,<br>
> ><br>
> > --<br>
> ><br>
> > Kaleb<br>
> ><br>
> > /30/2015 12:09 PM, Deepak Shetty wrote:<br>
> ><br>
> >><br>
> >><br>
> >> On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M <<a href="mailto:kshlmster@gmail.com">kshlmster@gmail.com</a><br>
> >> <mailto:<a href="mailto:kshlmster@gmail.com">kshlmster@gmail.com</a>>> wrote:<br>
> >><br>
> >> Hi all,<br>
> >> I had started a thread previously on the efforts we are undertaking<br>
> >> to improve thread synchronization in GlusterD [1]. I had mentioned<br>
> >> that we will be using RCU for synchronization and the userspace RCU<br>
> >> library (liburcu) [2] for implementation.<br>
> >><br>
> >> I am now in a almost in a position to submit changes to Gerrit for<br>
> >> review. But, I have an obstacle of making liburcu available on the<br>
> >> jenkins slaves.<br>
> >><br>
> >> I have begun development using the 0.8.6 version of liburcu, which<br>
> >> is the latest stable release. EPEL has liburcu packages for CentOS 6<br>
> >> and 7, but they are the of the older 0.7.* versions. Fedora has<br>
> >> packages more recent packages, but they are still older, 0.8.1. [3].<br>
> >><br>
> >> Considering the above situation with binary packages, I'm<br>
> >> considering adding liburcu into the GlusterFS tree as a part of<br>
> >> /contrib. This will be similar in vein to the argp-standalone library.<br>
> >><br>
> >> liburcu is licensed under LGPL-v2.1, so I don't think there is going<br>
> >> to be any problem including it. But IANAL, so I would like to know<br>
> >> of if this would if this is okay from a legal perspective.<br>
> >><br>
> >> I'll add the liburcu source to our tree and push the change for<br>
> >> review. I'm not really familiar with autotools, so I'll need some<br>
> >> help integrating it into our build system. I'll update the list when<br>
> >> I have pushed the change for review.<br>
> >><br>
> >><br>
> >> How do you intend to add, as a git submodule or ?<br>
> >> I had worked on GNU autotools in the past, but frankly don't remember<br>
> >> much of it. If any help is needed I can try, or can get someone to help<br>
> >> from my ex-company :)<br>
> >><br>
> >> thanx,<br>
> >> deepak<br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> Gluster-devel mailing list<br>
> >> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> >> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
> >><br>
> >><br>
> ><br>
<br>
> _______________________________________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</div></div></blockquote></div><br></div>