Re: Formal submission of Xtables2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

 - 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.

 - 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?

Now, don't dismiss these arguments.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux