30 Nov
2017
30 Nov
'17
4:59 p.m.
On 11/30/2017 5:49 PM, Fabio M. Di Nitto wrote:
On 11/30/2017 5:33 PM, Ferenc Wágner wrote:
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
"Fabio M. Di Nitto"
<fdinitto(a)redhat.com> writes:
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 :-)
On 11/30/2017 4:54 PM, Ferenc Wágner wrote:
Done, thanks. I hope this will help the
BSD builds...
"Fabio M. Di Nitto"
<fdinitto(a)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. 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. 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.