28 Nov
2017
28 Nov
'17
9:33 a.m.
On 11/28/2017 10:00 AM, Ferenc Wágner wrote:
I don´t think we have recorded them, but here is the rundown:
1) technically speaking using modules is no different than dlopening a
shared library.
In that respect, we are simply moving the problem somewhere else. I
could agree (based on the threads above)
that containing the problem within the same upstream is probably saner.
2) it enforces a strict internal API/ABI between main libknet and the
plugins. Making changes to those
very complex, specially during updates (see also point 4). Right
now we want to keep those API/ABI free to change
and expand.
3) it´s very difficult to debug modules due the symbol resolving
mechanism (Honza in CC can provide more details).
4) runtime operations (updates) can be nasty. You could have application
X that has loaded libknet 1.0 with modules 1.0
apt-get update.. get libknet 1.1 or whatever, new plugins,
application tries to load a module and kaboom.
#1 is mostly political/perception really. I don´t feel arguing much
about it, but the main point is that we are a very active
upstream and I don´t see a big issue (for now) to keep tracking
other libraries.
#2 i can probably live with, but that would have to be a project/group call.
#3 i am not happy about. specially given that the project is still in
it´s "early" days. this specifically has proven very challenging
in some environments.
#4 can be solved by adding some kind of hashing/signing mechanism of the
modules (aka load only modules that match
the build).
The patch size doesn´t scare me at all.
I am really concerned about point #2 and point #3 above. #4 can be
technically solved.
As for the code I have seen so far, please find another way to pass
log_msg down to the plugins. I am not going to export it to the world :-)
Fabio
"Fabio M. Di Nitto"
<fdinitto(a)redhat.com> writes:
Yeps, I have got time :-)
let me stop you a minute here.
Hey Fabio,
Thanks for looking at this experiment proactively! It reached the point
of viability right now, so let's chat about them if you have the time. (The patch set creates some rather obvious cleanup
opportunities, but I
guess we can leave them for later.)
Most of those concerns appears to be coming from a packing perspective.
I understand them, and some of them are valid.
what is the end goal of this work?
I tried
to summarize it in 96a92847:
Our current practice of dlopening foreign shared libraries is problematic
for several reasons:
* not portable: modules and shared libraries can be different object types
* dependency information is invisible (our canaries mostly solve this)
* hardwiring SONAMES breaks on transitions (KNET_PKG_SONAME solves this)
* symbol versioning information is lost (theoretically solvable)
The preferred way out is generating dynamically loaded private modules
from the main source, which then rely on the dynamic linker to load the
external symbols as usual.
For a longer version please refer to my mail at
https://lists.debian.org/debian-mentors/2017/11/msg00200.html and the
links included by Guillem Jover. We originally didn´t implement the modules model
because it has
several downsides for little benefit, based on the experience we had
with corosync modules in the past.
I'd be interested to learn about these
downsides, could you please
provide some hints or keywords to search for? I think it might be beneficial to have a chat
about those major changes
before you implement them :-) I *hate* for people to waste time on stuff
that might not merge.
Absolutely right. The true extent of the changes is
exaggerated by the
diffs (really, it just moves some definitions before their usage and
removes lots of boilerplate -- wasting the entirety of my previous
canary and soname works), but I'm still proposing an architectural
change. Those preprocessor tricks were neat; modules seem to be a
better solution to this problem set. Now tell me why they aren't. :)