| Message ID | alpine.LNX.2.01.1212130601210.9421@nerf07.vanv.qr |
|---|---|
| State | Rejected |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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