"Fabio M. Di Nitto" fdinitto@redhat.com writes:
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.)
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. :)