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