The local implementation is working well for liburcu-0.7. I'll be continuing with this approach as it is going to cover most of the systems we target. We can decide how we'll handle Debian Wheezy and Ubuntu Precise later.
~kaushal On Mon, Feb 2, 2015 at 3:00 PM, Kaushal M <kshlms...@gmail.com> wrote: > 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. > > 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. > > ~kaushal > > > On Mon, Feb 2, 2015 at 2:37 PM, Niels de Vos <nde...@redhat.com> wrote: > >> On Mon, Feb 02, 2015 at 09:10:36AM +0530, Kaushal M wrote: >> > 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. >> >> I do not like including libraries in the glusterfs sources. Currently >> there are several bits under contrib/ that do not see any maintenance. >> Who will be maintaining (fixing potential bugs, backporting newer >> versions, ...) for linurcu? Note that we support *many* different >> distributions, architectures and master+3 releases. >> >> It would be *so* much more efficient to use the distributions version of >> liburcu. Maybe it is possible to write some wrapper functions for the >> older versions of the library, and place those wrappers in contrib/ >> instead? >> >> Alternatively, we could maintain packages for liburcu in our >> repositories on download.gluster.org for distributions that do not have >> a recent enough version. You will need to find a relyable packager that >> agrees to take on this task. >> >> Niels >> >> > >> > ~kaushal >> > >> > >> > On Fri, Jan 30, 2015 at 6:30 PM, Kaleb KEITHLEY <kkeit...@redhat.com> >> wrote: >> > >> > > Hi, >> > > >> > > 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. >> > > >> > > Regards, >> > > >> > > -- >> > > >> > > Kaleb >> > > >> > > /30/2015 12:09 PM, Deepak Shetty wrote: >> > > >> > >> >> > >> >> > >> On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M <kshlms...@gmail.com >> > >> <mailto:kshlms...@gmail.com>> wrote: >> > >> >> > >> Hi all, >> > >> I had started a thread previously on the efforts we are >> undertaking >> > >> to improve thread synchronization in GlusterD [1]. I had >> mentioned >> > >> that we will be using RCU for synchronization and the userspace >> RCU >> > >> library (liburcu) [2] 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. >> [3]. >> > >> >> > >> 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 :) >> > >> >> > >> thanx, >> > >> deepak >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> Gluster-devel mailing list >> > >> Gluster-devel@gluster.org >> > >> http://www.gluster.org/mailman/listinfo/gluster-devel >> > >> >> > >> >> > > >> >> > _______________________________________________ >> > Gluster-devel mailing list >> > Gluster-devel@gluster.org >> > http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel