Patchwork Formal submission of Xtables2

login
register
mail settings
Submitter Jan Engelhardt
Date Dec. 13, 2012, 6 a.m.
Message ID <alpine.LNX.2.01.1212130601210.9421@nerf07.vanv.qr>
Download mbox
Permalink /patch/205742/
State Rejected
Headers show

Pull-request

git://git.inai.de/linux xtables2_a9

Comments

Jan Engelhardt - Dec. 13, 2012, 6 a.m.
Greetings.


This is Xtables2, a collective term used for much-sought enhancements
to the already-existing xtables infrastructure
(net/netfilter/x_tables.c and so on).

In this patch series of size 33, a new Netlink interface that gives
more flexibility for future extending is introduced, as well as a new
family-independent table space that removes the need to have the many
tables that classic {ip,ip6,eb,arp}tables does.

Network namespaces, arbitrary chain nesting and atomic rule
replacement as you know it is also retained/available again. Matches,
targets, verdicts (collectively known as actions) can appear in
arbitrary order. Existing xt_*.ko extensions continue to be usable,
provided they are coded for NFPROTO_UNSPEC operation. Of course,
there are more improvements planned.



Please consider for merging.

The set consists of some 33 patches. Do you want me to post them in 
chunks of ~11-13, or all at once, (or any other arrangement)?


Thanks everybody.

== git toolchain form output ==


The following changes since commit e4e541a84863b6a41f2427f59cc9156c644491a8:

  sock-diag: Report shutdown for inet and unix sockets (v2) (2012-10-23 14:57:52 -0400)

are available in the git repository at:

  git://git.inai.de/linux xtables2_a9

for you to fetch changes up to 1cf0d7b3398109bddf4e8bfb740fcc36a9ed72ed:

  netfilter: xtables2: support for goto action type (2012-12-13 06:30:38 +0100)

----------------------------------------------------------------
[The first two patches are needed for "base chain functionality",
but they live at the front so that I do not (did not)
get whole-kernel recompiles when amending any of the xtables2
commits, which is a relief.]

Jan Engelhardt (33):
      netfilter: add a private member to nf_hook_ops
      netfilter: make nf_hook_ops.priv available to hooks
      netfilter: xtables2: initial table skeletal functions
      netfilter: xtables2: initial Netlink interface
      netfilter: xtables2: chain creation and deletion
      netfilter: xtables2: transaction commit operation
      netfilter: xtables2: (atomic) table replace support
      netfilter: xtables2: transaction abort support
      netfilter: xtables2: redirect writes into transaction buffer
      netfilter: xtables2: supply a revision number
      netfilter: xtables2: chain dump support
      netfilter: xtables2: table dump support
      netfilter: xtables2: prepare for addition of more transaction buffer types
      netfilter: xtables2: implement the splice buffer
      netfilter: xtables2: skeleton for single rules and rule buffer
      netfilter: xtables2: core part for splice operation
      netfilter: xtables2: netlink part for splice operation
      netfilter: xtables2: rule entry handler
      netfilter: xtables2: rule dumping
      netfilter: xtables2: base chain functionality
      netfilter: xtables2: support nomination for chains
      netfilter: xtables2: support for entering/dumping rule verdicts
      netfilter: xtables2: execute verdicts in live rule traversal
      netfilter: xtables2: store netns in table and rule blob
      netfilter: xtables2: iterator for obtain/drop references to actions
      netfilter: xtables2: support for entering/dumping match actions
      netfilter: xtables2: execute matches in live rule traversal
      netfilter: xtables2: support for entering/dumping target actions
      netfilter: xtables2: execute targets in live rule traversal
      netfilter: xtables2: support for entering/dumping jumps
      netfilter: xtables2: provide a jump stack
      netfilter: xtables2: execute jump actions in live rule traversal
      netfilter: xtables2: support for goto action type

 include/linux/netfilter.h                        |   20 +-
 include/net/netfilter/xt_core.h                  |  275 ++++
 include/uapi/linux/netfilter/Kbuild              |    1 +
 include/uapi/linux/netfilter/nfnetlink.h         |    3 +-
 include/uapi/linux/netfilter/nfnetlink_xtables.h |  124 ++
 net/bridge/br_netfilter.c                        |   60 +-
 net/bridge/netfilter/ebtable_filter.c            |   16 +-
 net/bridge/netfilter/ebtable_nat.c               |   16 +-
 net/decnet/netfilter/dn_rtmsg.c                  |    9 +-
 net/ipv4/netfilter/arptable_filter.c             |    5 +-
 net/ipv4/netfilter/ipt_CLUSTERIP.c               |    6 +-
 net/ipv4/netfilter/iptable_filter.c              |    7 +-
 net/ipv4/netfilter/iptable_mangle.c              |   16 +-
 net/ipv4/netfilter/iptable_nat.c                 |   38 +-
 net/ipv4/netfilter/iptable_raw.c                 |    6 +-
 net/ipv4/netfilter/iptable_security.c            |    7 +-
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c   |   42 +-
 net/ipv4/netfilter/nf_defrag_ipv4.c              |   14 +-
 net/ipv6/netfilter/ip6table_filter.c             |    5 +-
 net/ipv6/netfilter/ip6table_mangle.c             |   10 +-
 net/ipv6/netfilter/ip6table_nat.c                |   39 +-
 net/ipv6/netfilter/ip6table_raw.c                |    5 +-
 net/ipv6/netfilter/ip6table_security.c           |    5 +-
 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c   |   44 +-
 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c        |   13 +-
 net/netfilter/Kconfig                            |    8 +-
 net/netfilter/Makefile                           |    2 +
 net/netfilter/core.c                             |    2 +-
 net/netfilter/ipvs/ip_vs_core.c                  |   40 +-
 net/netfilter/xt_core.c                          | 1473 +++++++++++++++++++++
 net/netfilter/xt_nfnetlink.c                     | 1520 ++++++++++++++++++++++
 net/netfilter/xt_nfnetlink.h                     |    7 +
 security/selinux/hooks.c                         |   47 +-
 33 files changed, 3646 insertions(+), 239 deletions(-)
 create mode 100644 include/net/netfilter/xt_core.h
 create mode 100644 include/uapi/linux/netfilter/nfnetlink_xtables.h
 create mode 100644 net/netfilter/xt_core.c
 create mode 100644 net/netfilter/xt_nfnetlink.c
 create mode 100644 net/netfilter/xt_nfnetlink.h


== Ohloh Line Count Summary ==

Language  Files       Code    Comment  Comment %      Blank      Total
--------  -----  ---------  ---------  ---------  ---------  ---------
c             4       2097        744      26.2%        283       3124
cpp           1        166         86      34.1%         23        275
--------  -----  ---------  ---------  ---------  ---------  ---------
Total         5       2263        830      26.8%        306       3399
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 13, 2012, 11 a.m.
On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
[...]
> Please consider for merging.

nftables and its compatibility layer already provide this and we will
not have to maintain two different netlink interfaces, which is too
much overhead.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 13, 2012, 11:36 a.m.
On Thursday 2012-12-13 12:00, Pablo Neira Ayuso wrote:

>On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
>[...]
>> Please consider for merging.
>
>nftables and its compatibility layer already provide this and we will
>not have to maintain two different netlink interfaces, which is too
>much overhead.

I refer you to our previous discussion on the topic
for the justifications:
http://www.spinics.net/lists/netfilter-devel/msg23919.html

Netlink is not the main selling point.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 13, 2012, 12:05 p.m.
On Thu, Dec 13, 2012 at 12:36:21PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 12:00, Pablo Neira Ayuso wrote:
> 
> >On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> >[...]
> >> Please consider for merging.
> >
> >nftables and its compatibility layer already provide this and we will
> >not have to maintain two different netlink interfaces, which is too
> >much overhead.
> 
> I refer you to our previous discussion on the topic
> for the justifications:
>
> http://www.spinics.net/lists/netfilter-devel/msg23919.html

I don't think that feature-set provides compelling reasons to push
this mainstream.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 13, 2012, 1:08 p.m.
On Thursday 2012-12-13 13:05, Pablo Neira Ayuso wrote:
>> >[...]
>> >> Please consider for merging.
>> >
>> >nftables and its compatibility layer already provide this and we will
>> >not have to maintain two different netlink interfaces, which is too
>> >much overhead.
>> 
>> I refer you to our previous discussion on the topic
>> for the justifications:
>>
>> http://www.spinics.net/lists/netfilter-devel/msg23919.html
>
>I don't think that feature-set provides compelling reasons to push
>this mainstream.

Well, if not that, then what - documentation, code size?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 13, 2012, 2:28 p.m.
On Thu, Dec 13, 2012 at 02:08:03PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 13:05, Pablo Neira Ayuso wrote:
> >> >[...]
> >> >> Please consider for merging.
> >> >
> >> >nftables and its compatibility layer already provide this and we will
> >> >not have to maintain two different netlink interfaces, which is too
> >> >much overhead.
> >> 
> >> I refer you to our previous discussion on the topic
> >> for the justifications:
> >>
> >> http://www.spinics.net/lists/netfilter-devel/msg23919.html
> >
> >I don't think that feature-set provides compelling reasons to push
> >this mainstream.
> 
> Well, if not that, then what - documentation, code size?

Not only that. Xtables2 (in its feature-set) inherits many of the
design decisions that were taken while designing iptables back in the
late nineties.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 13, 2012, 2:53 p.m.
On Thursday 2012-12-13 15:28, Pablo Neira Ayuso wrote:
>> >>
>> >> http://www.spinics.net/lists/netfilter-devel/msg23919.html
>> >
>> >I don't think that feature-set provides compelling reasons to push
>> >this mainstream.
>> 
>> Well, if not that, then what - documentation, code size?
>
>Not only that. Xtables2 (in its feature-set) inherits many of the
>design decisions that were taken while designing iptables back in the
>late nineties.

nf_tables itself retains some "late nineties" design decisions as
well.

In my opinion, there is nothing wrong with keeping some concepts. A
developer is not required to reevaluate and reinnovate every concept
there has been just for the heck of it. (The old "evolution, not
revolution" credo.) Throwing everything overboard generally does not
turn out to work these days.

That reminds me of Linus's statement from this year's LinuxCon:

	'''there were all these crazy people doing “innovative” operating
	systems, and they were all horrible. And they were trying to
	do things in new ways, and it turns out, sometimes, the old
	ways are the correct ways, and, you have done something for
	30 years one way, because that works.'''
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 13, 2012, 3:16 p.m.
On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
[...]
> In my opinion, there is nothing wrong with keeping some concepts. A
> developer is not required to reevaluate and reinnovate every concept
> there has been just for the heck of it. (The old "evolution, not
> revolution" credo.) Throwing everything overboard generally does not
> turn out to work these days.

Nobody is going to throw everything overboard. Nftables is backward
compatible while providing a new framework, revolutions are never
backward compatible.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 13, 2012, 4:41 p.m.
On Thursday 2012-12-13 16:16, Pablo Neira Ayuso wrote:

>On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
>[...]
>> In my opinion, there is nothing wrong with keeping some concepts. A
>> developer is not required to reevaluate and reinnovate every concept
>> there has been just for the heck of it. (The old "evolution, not
>> revolution" credo.) Throwing everything overboard generally does not
>> turn out to work these days.
>
>Nobody is going to throw everything overboard. Nftables is backward
>compatible while providing a new framework[,]

That sounds just like xt2. Compatibility exists such that there is a 
defined mapping from xt1->xt2 rules (at one point I did write a 
setsockopt translator in the past...); the userspace tool mimics 
iptables in syntax, though I have allowed myself to not have certain 
options in the CLI tool. New framework, same thing, I guess. xt_core is 
independent of xt_nfnetlink and I do not see any hurdle in introducing 
new concepts if so desired.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 13, 2012, 5:25 p.m.
On Thu, Dec 13, 2012 at 05:41:28PM +0100, Jan Engelhardt wrote:
> On Thursday 2012-12-13 16:16, Pablo Neira Ayuso wrote:
> 
> >On Thu, Dec 13, 2012 at 03:53:45PM +0100, Jan Engelhardt wrote:
> >[...]
> >> In my opinion, there is nothing wrong with keeping some concepts. A
> >> developer is not required to reevaluate and reinnovate every concept
> >> there has been just for the heck of it. (The old "evolution, not
> >> revolution" credo.) Throwing everything overboard generally does not
> >> turn out to work these days.
> >
> >Nobody is going to throw everything overboard. Nftables is backward
> >compatible while providing a new framework[,]
> 
> That sounds just like xt2. Compatibility exists such that there is a 
> defined mapping from xt1->xt2 rules (at one point I did write a 
> setsockopt translator in the past...); the userspace tool mimics 
> iptables in syntax, though I have allowed myself to not have certain 
> options in the CLI tool.

We provided that compatibility layer that mimics iptables in Oct 2012
[1]. However, it seems you prefered to code it your way from almost
scratch, that's confusing.

> New framework, same thing, I guess. xt_core is independent of
> xt_nfnetlink and I do not see any hurdle in introducing new concepts
> if so desired.

We have already new concepts in nftables, have a look at it.

Please, I think this conversation just started spinning and the same
arguments are showing up over and over again, it's time to stop this.

[1] http://www.spinics.net/lists/netfilter-devel/msg23831.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 13, 2012, 6:19 p.m.
On Thursday 2012-12-13 18:25, Pablo Neira Ayuso wrote:
>> >> turn out to work these days.
>> >
>> >Nobody is going to throw everything overboard. Nftables is backward
>> >compatible while providing a new framework[,]
>> 
>> That sounds just like xt2. Compatibility exists such that there is a 
>> defined mapping from xt1->xt2 rules (at one point I did write a 
>> setsockopt translator in the past...); the userspace tool mimics 
>> iptables in syntax, though I have allowed myself to not have certain 
>> options in the CLI tool.
>
>We provided that compatibility layer that mimics iptables in Oct 2012
>[1]. However, it seems you prefered to code it your way from almost
>scratch, that's confusing.

That's just not true; I did post before on the xt2 matter as well,
in its various stages.

xtables2_a8: http://marc.info/?l=netfilter-devel&m=132699055220975&w=2
xtables2_a7: https://lwn.net/Articles/426896/
             https://lwn.net/Articles/417619/

There is even older experimenting stuff in my git repo, which you
can look at. (The dates are not forged - you will have to trust me
on that.)



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.
That thought _terrifies_ me, and were it so, it would not be an
environment I want to work in.

Just say so if I am to GTFO.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 16, 2012, 11:57 p.m.
Hi Andreas,

On Fri, Dec 14, 2012 at 10:41:41AM +0100, Andreas Herz wrote:
> On 13/12/12 at 12:00, Pablo Neira Ayuso wrote:
> > On Thu, Dec 13, 2012 at 07:00:07AM +0100, Jan Engelhardt wrote:
> > [...]
> > > Please consider for merging.
> > 
> > nftables and its compatibility layer already provide this and we will
> > not have to maintain two different netlink interfaces, which is too
> > much overhead.
> 
> Apart of your discussion (i think it's quite interesting although
> you might not agree), is there a summary of the status of nftables?
> The last time i read about it, while i was at the university, i
> thought it was dead.  I read that Patrick McHardy was the one
> pushing the project but never heard any news after 2010. Now i read
> that Pablo is taking care of it.

It's true that nftables suffered an hiatus in its development, but
we're back on it and there has been quite a lot of activity on it
recently. This is the kernel branch, you can check the changelog here:

http://1984.lsi.us.es/git/nf-next/log/?h=nf_tables8

And there's an iptables compatibility layer that is ready for IPv4,
you can find details here:

http://www.spinics.net/lists/netfilter-devel/msg23831.html

> So i would love to hear more details on the roadmap for nftables, might
> be interesting for me and my work here.

I understand you want to know more on the future of nftables, but
because the way I am, I prefer to skip "hot air" wording by now and
talk on code done anytime soon.

So I have to request some patience from you. We promise to deliver as
much information as possible once we are done with the core features.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 17, 2012, 12:08 a.m.
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. Discrediting me
here in the mailing list and everywhere and using irritating wording
will not help to get this mainstream. Stop this.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 17, 2012, 1:39 a.m.
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-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 17, 2012, 9:53 a.m.
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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Maciej Żenczykowski - Dec. 17, 2012, 10:12 a.m.
> 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.

So far, Pablo, you've yet to make any argument whatsoever.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 17, 2012, 1:01 p.m.
On Monday 2012-12-17 10:53, Pablo Neira Ayuso wrote:
>>  - 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.

Multiple table objects are possible in Xtables2, I do not think
it's something exclusive to nft.
It is just that I do not see a usecase and hence a need for multiple
active tables, so the netns only stores one.


>>  - 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.
>
>We have also planned adding agnostic tables to avoid the IPv4/IPv6 cases.

So now xt2 gets copied... hmm must be a successful concept :)


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

There are no traces of pernet operations for nft in 3cb3000158^{tree}.


>> Now, don't dismiss these arguments.
>
>So far, I haven't see any *strong reason* to drop nftables code

In all fairness, I have never said anything about dropping nft.
I am focused on xt2, its inclusion and subsequent maintenance, because 
it resolves the ipt shortcomings in a way that I think appeals most to 
the userspace crowd.


>and write something from scratch as flexible as it is

I am avoiding from-scratch where possible. Given that ip_tables.c
exposes its ABI to userspace so much and deferred ruleset operations
to userspace as well, it is nearly impossible to change, and so
inherently, there will be some new code for any future replacement.
But it is my credo to reuse, and I do.


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

How are users supposed to know how nftables is designed?

Xtables2 has documentation, explains where and why it deviates from 
iptables. If there is only a doubt in your mind, @Dear Users, mail it -
I want the doc to leave no question unanswered.


If the "flexibility" mentioned above is important to you, I encourage
you to checkout xtables2 and give some thought on how your feature
could be integrated into it. Or rather, I'll offer on top: describe
the feature, and I write it.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pablo Neira - Dec. 17, 2012, 2:30 p.m.
On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
[...]
> >So far, I haven't see any *strong reason* to drop nftables code
> 
> In all fairness, I have never said anything about dropping nft.
> I am focused on xt2, its inclusion and subsequent maintenance, because 
> it resolves the ipt shortcomings in a way that I think appeals most to 
> the userspace crowd.

I'm still not convinced but I want find a short-term compromise
solution for this which does not involve tons of email. We'll announce
the netfilter workshop soon, likely to happen at Q1 2013 depending on
availability of the organizer, but maybe Q2 2013 (but not later), I
think it's the place to debate your proposal and nftables, of course.

I will not get anything into mainline until then.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 17, 2012, 8:51 p.m.
On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:

>On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
>[...]
>> >So far, I haven't see any *strong reason* to drop nftables code
>> 
>> In all fairness, I have never said anything about dropping nft.
>> I am focused on xt2, its inclusion and subsequent maintenance, because 
>> it resolves the ipt shortcomings in a way that I think appeals most to 
>> the userspace crowd.
>
>I'm still not convinced but I want find a short-term compromise
>solution for this which does not involve tons of email. We'll announce
>the netfilter workshop soon, likely to happen at Q1 2013 depending on
>availability of the organizer, but maybe Q2 2013 (but not later), I
>think it's the place to debate your proposal and nftables, of course.
>
>I will not get anything into mainline until then.

Delaying this for more months is not a good idea, I think.

The amount of patches will grow as more features are implemented. If
there is an objection to a patch, then this can have implications for
all those that follow (not rebase conflicts, but actual
invalidating), which gets more painful the larger the patchset is.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jozsef Kadlecsik - Dec. 17, 2012, 11:49 p.m.
On Mon, 17 Dec 2012, Jan Engelhardt wrote:

> On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:
> 
> >On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
> >[...]
> >> >So far, I haven't see any *strong reason* to drop nftables code
> >> 
> >> In all fairness, I have never said anything about dropping nft.
> >> I am focused on xt2, its inclusion and subsequent maintenance, because 
> >> it resolves the ipt shortcomings in a way that I think appeals most to 
> >> the userspace crowd.
> >
> >I'm still not convinced but I want find a short-term compromise
> >solution for this which does not involve tons of email. We'll announce
> >the netfilter workshop soon, likely to happen at Q1 2013 depending on
> >availability of the organizer, but maybe Q2 2013 (but not later), I
> >think it's the place to debate your proposal and nftables, of course.
> >
> >I will not get anything into mainline until then.
> 
> Delaying this for more months is not a good idea, I think.
> 
> The amount of patches will grow as more features are implemented. If
> there is an objection to a patch, then this can have implications for
> all those that follow (not rebase conflicts, but actual
> invalidating), which gets more painful the larger the patchset is.

A few months won't really hurt - TPROXY had been discussed for a couple of 
years at every workshop (and it was much simpler, smaller code). Both 
nftables and xtables2 have got nice features, so it's not a simple 
question.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Engelhardt - Dec. 18, 2012, 1:11 a.m.
On Tuesday 2012-12-18 00:49, Jozsef Kadlecsik wrote:
>>>
>>>I'm still not convinced [...] I will not get anything into mainline 
>>>until then.
>>
>>Delaying this for more months is not a good idea, I think. The amount 
>>of patches will grow as more features are implemented.[...]
>
>A few months won't really hurt - TPROXY had been discussed for a couple 
>of years at every workshop (and it was much simpler, smaller code). 
>Both nftables and xtables2 have got nice features, so it's not a simple 
>question.

Ok.
I'll go with your mediating words. :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - Dec. 18, 2012, 1:27 a.m.
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Tue, 18 Dec 2012 00:49:26 +0100 (CET)

> On Mon, 17 Dec 2012, Jan Engelhardt wrote:
> 
>> On Monday 2012-12-17 15:30, Pablo Neira Ayuso wrote:
>> 
>> >On Mon, Dec 17, 2012 at 02:01:07PM +0100, Jan Engelhardt wrote:
>> >[...]
>> >> >So far, I haven't see any *strong reason* to drop nftables code
>> >> 
>> >> In all fairness, I have never said anything about dropping nft.
>> >> I am focused on xt2, its inclusion and subsequent maintenance, because 
>> >> it resolves the ipt shortcomings in a way that I think appeals most to 
>> >> the userspace crowd.
>> >
>> >I'm still not convinced but I want find a short-term compromise
>> >solution for this which does not involve tons of email. We'll announce
>> >the netfilter workshop soon, likely to happen at Q1 2013 depending on
>> >availability of the organizer, but maybe Q2 2013 (but not later), I
>> >think it's the place to debate your proposal and nftables, of course.
>> >
>> >I will not get anything into mainline until then.
>> 
>> Delaying this for more months is not a good idea, I think.
>> 
>> The amount of patches will grow as more features are implemented. If
>> there is an objection to a patch, then this can have implications for
>> all those that follow (not rebase conflicts, but actual
>> invalidating), which gets more painful the larger the patchset is.
> 
> A few months won't really hurt - TPROXY had been discussed for a couple of 
> years at every workshop (and it was much simpler, smaller code). Both 
> nftables and xtables2 have got nice features, so it's not a simple 
> question.

Agreed.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html