Re: [RFC PATCH IPTABLES 0/12]: matches/targets unification

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> Hi, all,
> 
> This patch series enables to unify matches/targets of ip[6]tables.
> 
> I've changed the only parts to unify register_{match,target} and
> moves duplicated functions to a file. Unfortunately, I had to change some
> arguments of the traditional APIs for them, but they are to avoid
> warning on compilation.
> 
> It might not be good time to submit this because of recent patch rush
> and it's just before next release of iptables, so it's just RFC this time.

I just released 1.3.7, so I think we could add this now.

Since the next version will be more than just a bugfix release,
one thing I wanted to bring up for some time ..

We currently have lots of extensions in iptables for non-mainline
matches and targets, some obsolete, some already decided against
merging and some that might be merged in the future. For the
extensions belonging to a feature that won't be merged, the same
argument applies as to POM, they increase the maintenance burden
and should really be maintained along with the kernel patch (and
pom already supports patching iptables).

More problematic are extensions for stuff that might get merged.
In many cases so far they were included by distributors if
compiled by default, but when merging a feature we often noticed
that the ABI had problems like 32/64 bit issues and needed to be
changed before merging, which effectively broke compatibility.
I think it would be preferable to have people wait until their
distribution releases a new version to use a new feature than
have strange and unexplained errors.

So, what I'm proposing is to remove all extensions that are
neither part of 2.4 or 2.6 from iptables, pushing those for
externally maintained patches to the patch maintainers, those
for patches maintained in pom to pom, and delete the rest.

Comments?