Re: Avoiding multiple calls to xt_target.checkentry

[Patrick McHardy <kaber@trash.net>]

Jan Engelhardt wrote:
> On Thursday 2009-11-05 16:00, Patrick McHardy wrote:
>> Adam Nielsen wrote in summer 2009:
>>>>> Thanks for the explanation!  So - to get it straight in my mind - the
>>>>> checkentry function will be called multiple times while the trigger
>>>>> exists,
>>>>> but is the destroy function also called multiple times?  Or is checkentry
>>>>> called whenever tables are created, but destroy only ever called once
>>>>> when the
>>>>> table is removed for the last time?
>>>> They will always be called an equal amount of times - each one
>>>> once per target instance.
>>> Great, thanks for the info (thanks Jan too!)  I'm working on a patch so I'll
>>> post it when I think I've solved the issue correctly.
>> Just wondering whether there's still hope for this issue to get fixed.
>>
>> I haven't added the LED extension to iptables yet, so if there's no
>> interest in fixing this, we can remove the LED target again.
> 
> An increasing number of modules want to keep a global state.
> Currently, xt_recent and xt_RATEEST do that in the kernel; xt_quota3
> (Xt-a) also does its own management — basically just a
> name=>personal_struct mapping —, and xt_LED would now need such state
> keeping too. It seems preferable to somehow join that together and
> funnel that into xtables.c. What do you think?
> Meanwhile, let me prep some commit.

If this can be done clean and simple, sure. I have my doubt though,
since it needs a mapping of the old rule to the new rule.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html