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
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
liburcu is licensed under LGPLv2.1, and can be used by any software
compatible with LGPL. IBM, the owners of the patent, provided their
approval for this licensing [1]. We are good with regards to this.
The liburcu homepage mentions that it has been tested on Linux and FreeBSD,
but it should work
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
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
On Thu, Jan 29, 2015 at 5:05 PM, Kaushal M 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
