Comment # 8 on bug 1037309 from zhen ren

Hi Tomas,

(In reply to Tom���� Chv��tal from comment #7)
> > That's about implementation then, which would need much changes in
> > upstream...
> 
> Yup, we need to tell upstream. Or patch it like we did with cluster part.
> > 

Honestly, I'm not going to do that, because:
1. I don't know exactly what the problem is in upstream code, and how much
efforts it takes to work out a patch for it. It's useless to just tell upstream
that "Hi, lvmlock doesn't work for us if we package it separately", without
giving strong reasons and respective patch set.

2. Patch it like what? Sorry, I don't catch up with you here. I don't think
it's worthy changing code much so that we can just build lvmlockd separately. 
Honestly, I neither have time nor interest to do so.

3. As you can see in the mailist, upstream is working a stable release now:
"""
Version 2.02.171
Another development checkpoint release. We have stopped adding features as we
work towards the next stable release,
but please still only use this release for testing purposes while we continue
to find and fix bugs.
"""
This is not a bug, but maybe a design defect. I can imagine it's hard to
persuade upstream to accept
big change for it even if we work out a patch set. 

> > > 
> > > And of course the header must not inline those functions in either case.
> > 
> > Why?
> > I think removing all "inline" in the header couldn't solve this problem,
> > right?
> > 
> 
> In theory, we would rely on the compiler to not inline the code if it is not
> specified, there are some complexity calculations whether to do it or not,
> try it and let us see ;)

Only removing the "inline" modifiers would not make a difference, I realize. In
addition,
having the call declarations in header file and moving their definitions (both
real and empty
functions) to source files may work around. Let me have a try;-)

Thanks,
Eric