From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: Florian Westphal <fw@strlen.de>,
netfilter-devel@vger.kernel.org, arturo.borrero.glez@gmail.com
Subject: Re: [PATCH nft v2 3/3] src: add xt compat support
Date: Fri, 10 Apr 2015 02:26:50 +0200 [thread overview]
Message-ID: <20150410002649.GA6929@salvia> (raw)
In-Reply-To: <20150410000533.GG13473@acer.localdomain>
On Fri, Apr 10, 2015 at 01:05:33AM +0100, Patrick McHardy wrote:
> On 10.04, Pablo Neira Ayuso wrote:
> > On Fri, Apr 10, 2015 at 12:45:05AM +0100, Patrick McHardy wrote:
> > [...]:
> > > I want this decision to be made based on what users actually need and
> > > on what they need it for. Not basically pull in everything from iptables
> > > in one go without even thinking about it.
> > >
> > > As a middle ground, I think I could agree to adding the xt compat
> > > framework, but only allow selective extensions to be used where we
> > > are sure we need them.
> >
> > The framework fully supports this, imposing an artificial limitation
> > makes no sense to me at all.
>
> I'm aware that its technically possible, the question is a different one.
Then, if it's technically possible with the existing kernel framework
(and exposed to userspace), there is basically no way that we can
limit what userspace can do with this.
> > And more importantly, without this patch nft breaks when users
> > load their ruleset throught iptables-compat-restore.
>
> How will it break if we don't support it so far?
It's currently broken, and we have already distro packaging
iptables-compat.
> > With that artificial limitation, some rulesets will break, some other
> > not.
> >
> > Admit it, there is no way we can control what users will do in the
> > future. The only way out is to move forward in an evolutionary
> > fashion.
>
> Right. But this is not evolutionary. It pulls everything we have in
> iptables in nftables in one big dump. Its the opposite of evolution.
> An evolutionary process would be to grow things as they are needed,
> which is what I'm suggesting.
No. Evolution is to extend things from what you already have, and let
just things extinct by providing better alternatives.
next prev parent reply other threads:[~2015-04-10 0:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 16:55 [PATCH nft v2 1/3] include: cache ip_tables.h, ip6_tables.h, arp_tables.h and ebtables.h Pablo Neira Ayuso
2015-04-09 16:55 ` [PATCH nft v2 2/3] src: expose delinearize/linearize structures and stmt_error() Pablo Neira Ayuso
2015-04-09 16:55 ` [PATCH nft v2 3/3] src: add xt compat support Pablo Neira Ayuso
2015-04-09 20:36 ` Patrick McHardy
2015-04-09 20:51 ` Florian Westphal
2015-04-09 22:34 ` Pablo Neira Ayuso
2015-04-09 22:36 ` Florian Westphal
2015-04-09 22:56 ` Pablo Neira Ayuso
2015-04-09 23:23 ` Patrick McHardy
2015-04-09 23:40 ` Pablo Neira Ayuso
2015-04-09 23:45 ` Patrick McHardy
2015-04-09 23:59 ` Pablo Neira Ayuso
2015-04-10 0:05 ` Patrick McHardy
2015-04-10 0:26 ` Pablo Neira Ayuso [this message]
2015-04-10 0:33 ` Patrick McHardy
2015-04-09 23:22 ` Patrick McHardy
2015-04-09 23:21 ` Patrick McHardy
2015-04-09 23:44 ` Pablo Neira Ayuso
2015-04-09 23:48 ` Patrick McHardy
2015-04-10 0:07 ` Pablo Neira Ayuso
2015-04-10 0:11 ` Patrick McHardy
2015-04-10 0:36 ` Pablo Neira Ayuso
2015-04-10 0:36 ` Patrick McHardy
2015-04-10 1:00 ` Pablo Neira Ayuso
2015-04-09 22:33 ` Pablo Neira Ayuso
2015-04-09 23:18 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150410002649.GA6929@salvia \
--to=pablo@netfilter.org \
--cc=arturo.borrero.glez@gmail.com \
--cc=fw@strlen.de \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).