Re: [PATCH 11/11] netfilter: xtables: convert basic nfproto match functions into xt matches

Re: [PATCH 11/11] netfilter: xtables: convert basic nfproto match functions into xt matches

[Jan Engelhardt]

On Tuesday 2010-05-11 14:59, Patrick McHardy wrote:

>Jan Engelhardt wrote:
>> Each table implementation has a private built-in hardwired match
>> function for its corresponding nfproto data (e.g. ip_tables: struct
>> ipt6_ip6 processed by ip6_packet_match to match against the IPv6
>> header, etc.)
>> 
>> Rewrite the functions so that they are independent xt_matches and can
>> be used from an nfproto-independent table.
>
>No major objections, but I'd like to know where this is going
>and when, so far this doesn't provide any benefit.

The plan, as posted last fall[1], is to continue generalizing the 
different iptables copies into one, bringing Xtables up to the next 
level, e.g. family-agnostic rulesets, while retaining 
compatibility.

[1] http://lwn.net/Articles/345176/

The "when" originally was 2.6.32, but I got a little slacky in doing 
requested benchmarks, so it had practically postponed itself to the 
current cycle, 2.6.35. If my counting is right, ~41 patches of that 
list[1] have been merged, and while doing that, 46 concurrent 
commits/ideas of mine have also been merged.

There are at least 60 patches left however, and that does not include 
any comments from your side. I guess I don't get to spool and flush the 
entire queue to 2.6.35 anymore - "better luck next time", or?

>And as always, please format things like
>
>> +	ret = ifname_compare_aligned((par->in == NULL) ? nulldevname :
>> +	      par->in->name, ipinfo->iniface, ipinfo->iniface_mask);
>
>so the arguments are neatly aligned. F.i.
>
>	ret = ifname_compare_aligned(!par->in ? nulldevname : par->in->name,
>				     ipinfo->iniface, ipinfo->iniface_mask);
>
>would work nicely.
>

Will revisit.

Re: [PATCH 11/11] netfilter: xtables: convert basic nfproto match functions into xt matches

[Patrick McHardy]

Jan Engelhardt wrote:
> On Tuesday 2010-05-11 14:59, Patrick McHardy wrote:
> 
>> Jan Engelhardt wrote:
>>> Each table implementation has a private built-in hardwired match
>>> function for its corresponding nfproto data (e.g. ip_tables: struct
>>> ipt6_ip6 processed by ip6_packet_match to match against the IPv6
>>> header, etc.)
>>>
>>> Rewrite the functions so that they are independent xt_matches and can
>>> be used from an nfproto-independent table.
>> No major objections, but I'd like to know where this is going
>> and when, so far this doesn't provide any benefit.
> 
> The plan, as posted last fall[1], is to continue generalizing the 
> different iptables copies into one, bringing Xtables up to the next 
> level, e.g. family-agnostic rulesets, while retaining 
> compatibility.
> 
> [1] http://lwn.net/Articles/345176/
> 
> The "when" originally was 2.6.32, but I got a little slacky in doing 
> requested benchmarks, so it had practically postponed itself to the 
> current cycle, 2.6.35. If my counting is right, ~41 patches of that 
> list[1] have been merged, and while doing that, 46 concurrent 
> commits/ideas of mine have also been merged.
> 
> There are at least 60 patches left however, and that does not include 
> any comments from your side. I guess I don't get to spool and flush the 
> entire queue to 2.6.35 anymore - "better luck next time", or?

Well, I have no problems already merging parts that make sense on
their own, but this patchset kind of stops in the middle.

My suggestions would be for me to merge patches 01-08 and you
include the remaining ones in a series that actually need that
change. If you manage to submit that series in time for 2.6.35,
even better. How does that sound?

Re: [PATCH 11/11] netfilter: xtables: convert basic nfproto match functions into xt matches

[Jan Engelhardt]

On Tuesday 2010-05-11 15:45, Patrick McHardy wrote:
>> 
>> The plan, as posted last fall[1], is to continue generalizing the 
>> different iptables copies into one, bringing Xtables up to the next 
>> level, e.g. family-agnostic rulesets, while retaining 
>> compatibility.
>> 
>> [1] http://lwn.net/Articles/345176/
>> 
>> The "when" originally was 2.6.32, but I got a little slacky in doing 
>> requested benchmarks, so it had practically postponed itself to the 
>> current cycle, 2.6.35. If my counting is right, ~41 patches of that 
>> list[1] have been merged, and while doing that, 46 concurrent 
>> commits/ideas of mine have also been merged.
>> 
>> There are at least 60 patches left however, and that does not include 
>> any comments from your side. I guess I don't get to spool and flush the 
>> entire queue to 2.6.35 anymore - "better luck next time", or?
>
>Well, I have no problems already merging parts that make sense on
>their own, but this patchset kind of stops in the middle.

I felt it made more sense to cut at 11 rather than 8. The next
coherent batch would start introducing pure new code and would
already be one of size 29. I mean I don't mind, you will look
through them either way ;-)

>My suggestions would be for me to merge patches 01-08 and you
>include the remaining ones in a series that actually need that
>change. If you manage to submit that series in time for 2.6.35,
>even better. How does that sound?

Always fine by me.