On Monday 2009-08-24 14:53, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>> For a following patch in this series ("generate nf hook ops on
>> demand"), we will be requiring that a single hook entry function per
>> table does the processing. Would this not be done would I need to
>> pass multiple hook functions as arguments in that later patch, which
>> would have been not so nice.
>
>Removing duplicates is fine of course, but I don't like the
>"consolidation" of multiple different hook functions very much.
>You're trading more runtime overhead (admittedly not that much,
>but those functions are heavily used)
Heavily? Most systems run the initialization exactly once.
>The second problem is that your automatically generated hook ops
>can't even represent all the cases we have since some tables
>actually do use different priorities for the different hooks.
I never claimed it was a fits-it-all solution. The nat table
still has its original scheme.
>And I'm not sure where the memory savings you claim should come
>from, the hook ops are still required at runtime.
Hm, true. That's why someone is supposed to look over them :>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
