Jan Engelhardt wrote:
> 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.
I'm talking about the hook functions.
>> 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
