On 11/30/2017 5:49 PM, Fabio M. Di Nitto wrote:
On 11/30/2017 5:33 PM, Ferenc Wágner wrote:
"Fabio M. Di Nitto" fdinitto@redhat.com writes:
On 11/30/2017 4:54 PM, Ferenc Wágner wrote:
"Fabio M. Di Nitto" fdinitto@redhat.com writes:
On 11/30/2017 3:26 PM, Ferenc Wágner wrote:
You made me curious. Let me try to implement it... OK, I rebased and squashed my branch somewhat. I'm pushing it as modules2, we had some very similar ideas and some different ones!
can you please rebase it on top of the latest modules branch? it´s missing / reverting the latest spec file changes.
Not easily, but I cherry-picked them, hope it helps.
Ack, not a problem. We might need to cherry pick a bit more (like the valgrind exception for BSD), but let see.
Done, thanks. I hope this will help the BSD builds...
Also, I see you are #define KNET_MODULE for each module to handle the log_msg and you need to pass log_msg symbols around on each load.
I am not against that patch, but i think just passing the pointer around via knet_h is less invasive and needs less "magic" :-)
Either way works for me, I don't know enough about knet_h to tell whether a pointer to log_msg belongs there. Mainly, I wanted to try and offer this approach. Since it's a fixed value, storing it separately in each handle seems a little awkward.
Yeah I see your point. knet_h is completely hidden from the user, so it doesn´t matter what we store there internally (so to speak).
Most applications will have one or two handles, I doubt we will see a proliferation of many handles :-)
BTW it's possible to get rid of the KNET_MODULE defines by using indirection even inside libknet core. Efficiency surely suffers more due to my ops structure than this. But again I find that straightforward, so maybe worth it... It's a pity it has to go through a void * in load_module().
Yeah.. I don´t have a strong opinion. Chrissie? do you mind to be quorum discriminator here? ;)
PS I love the work on configure.ac, that´s definitely going in.
I spent quite some time trying to avoid introducing new defines, but no preprocessor magic I could come up with cut it. On the other hand, the original BUILD* macros now see very little use (two tests only). Splitting those tests would let us get rid of the defines and use the identically named Automake conditionals exclusively. Which would be a nice cleanup in my opinion.
Sure, go for it.
actually, even easier, just check if the plugin is built with knet_handle_get_(compress|crypto)_list and do or skip the test.
Fabio