Mailinglist Archive: opensuse-bugs (4283 mails)

< Previous Next >
[Bug 1037309] [lvmlockd regression] lvmlockd always fails to behave in latest version 2.02.170
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Mon, 08 May 2017 02:59:38 +0000
  • Message-id: <bug-1037309-21960-covLn8o0dE@http.bugzilla.suse.com/>
http://bugzilla.suse.com/show_bug.cgi?id=1037309
http://bugzilla.suse.com/show_bug.cgi?id=1037309#c8

--- Comment #8 from zhen ren <zren@xxxxxxxx> ---
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

--
You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >
References