[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180219171411.GG15918@orbyte.nwl.cc>
Date: Mon, 19 Feb 2018 18:14:11 +0100
From: Phil Sutter <phil@....cc>
To: David Miller <davem@...emloft.net>
Cc: laforge@...monks.org, fw@...len.de, daniel@...earbox.net,
netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter
Hi David,
On Mon, Feb 19, 2018 at 10:44:59AM -0500, David Miller wrote:
> From: Harald Welte <laforge@...monks.org>
> Date: Mon, 19 Feb 2018 16:38:08 +0100
>
> > On Mon, Feb 19, 2018 at 10:27:27AM -0500, David Miller wrote:
> >> > Would you be willing to merge nftables into kernel tools directory
> >> > then?
> >>
> >> Did you miss the part where I explained that people explicitly disable
> >> NFTABLES in their kernel configs in most if not all large datacenters?
> >
> > If people to chose to disable a certain feature, then that is their own
> > decision to do so. We should respect that decision. Clearly they seem
> > to have no interest in a better or more featureful packet filter, then.
> >
> > I mean, it's not like somebody proposes to implement NTFS inside the FAT
> > filesystem kernel module because distributors (or data centers) tend to
> > disable the NTFS module?!
> >
> > How is kernel development these days constrained by what some users may
> > or may not put in their Kconfig? If they want a given feature, they
> > must enable it.
>
> This discussion was about why iptables UABI still matters.
>
> And I'm trying to explain to you one of several reasons why it does.
>
> Also, instead of saying "They decided to not use NFTABLES, oh well
> that is their problem" it might be more beneficial, especially in the
> long term for netfilter, to think about "why".
OK, so reading between the lines you're saying that nftables project has
failed to provide an adequate successor to iptables?
Cheers, Phil
Powered by blists - more mailing lists