[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180219.104459.157566294655687535.davem@davemloft.net>
Date: Mon, 19 Feb 2018 10:44:59 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: laforge@...monks.org
Cc: 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
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".
Powered by blists - more mailing lists