Re: Formal submission of Xtables2

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Dec 17, 2012 at 02:39:07AM +0100, Jan Engelhardt wrote:
> On Monday 2012-12-17 01:08, Pablo Neira Ayuso wrote:
> 
> >On Thu, Dec 13, 2012 at 07:19:28PM +0100, Jan Engelhardt wrote:
> >[...]
> >> Each of us are (understandably) biased, as each has contributed
> >> to "their" implementation. But, you also have the decisive power as
> >> the Linux kernel Netfilter subsystem maintainer, and I fear that you
> >> might use this to reject xt2 to force nft.
> >
> >I have to ask you to stick to technical arguments.
> 
> Ok, let me try again then. We should merge xtables2, because
> (some selected arguments follow):
> 
>  - It brings a NL-type (<- long-sought) interface
> 
>  - It uses a single table because there simply is no need
>    to have multiple ones. This has benefits for replacement atomicity 
>    guarantees, and gives some memory previously spent for modules
>    back to the user, for example.

You can implement this with nftables. Actually, nftables allows you to
have as many tables as you want. No matter what configuration you
select, it's extremely flexible.

>  - This table is NFPROTO_UNSPEC which means that the duplication of
>    rules between ip(4)tables and ip6tables users had to make is
>    gone, meaning less maintenance/complexity/etc. for the administrator, 
>    and of course, less rules lead to less memory usage.

Once single table means no table at all to me. We have also planned
adding agnostic tables to avoid the IPv4/IPv6 cases.

>  - and because it retains some characteristics, for example
>    atomic replaces and netns.
> 
> >You wrote on Thu, 13 Dec 2012 13:05:09 +0100:
> >>I don't think that feature-set provides compelling reasons to push [xt2]
> 
>    Not everybody cares about these things, that would be unrealistic.
>    However, some users, and me included, _do have_ an interest in having
>    what is presented, because they do e.g. run containers. Otherwise,
>    we would not be having netns in iptables today, right?

Again, those are completely possible with nftables.

> Now, don't dismiss these arguments.

So far, I haven't see any *strong reason* to drop nftables code and
write something from scratch as flexible as it is, my impression is
that you don't know how nftables is designed and it works, so you'll
have to tell me why I'm wrong.

As said, please provide convincing arguments, no more rants.