Re: [PATCH nft v2 3/3] src: add xt compat support

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Apr 10, 2015 at 12:23:41AM +0100, Patrick McHardy wrote:
> On 10.04, Pablo Neira Ayuso wrote:
> > On Fri, Apr 10, 2015 at 12:36:22AM +0200, Florian Westphal wrote:
> > > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > >
> > > > > Whats the point of providing a 'native' replacement for an existing xtables
> > > > > target if we can just use the xtables version?
> > > > 
> > > > Have a look a hashlimit, multiport and all of our existing combo
> > > > match/targets.  They are a mess. We're now going towards a way more
> > > > flexible and generic (lego fashion) framework that will provide all
> > > > kind of combos without relying on this kind of Frankenstein
> > > > extensions.
> > > 
> > > Sure, but do you really want to add native expression equivalents for
> > > things like quota match, '-m time', '-j CLUSTERIP' ... ?
> > 
> > We don't want to rush to add a native expression that is going to map 1:1
> > to these matches/targets. We need time to think and to discuss how to
> > implement these in a nice (generic) fashion.
> > 
> > But if users need these features, they can migrate to nftables while
> > keeping those in their ruleset through compat.
> 
> But if they don't tell us what they need, how are we supposed to know?
> This removes it from decision making and our sight entirely.

We know we have to provide native replacements for what we have
already.

> > > And wrt. the existing combos, are you positive that your xlate tool
> > > will always be able to translate everything to nft native expressions?
> > >
> > > I'm specifically thinking about side-effects, e.g. -m recent which can
> > > also be manipulated externally to ruleset via /proc...
> > > 
> > > So i am afraid that 100% compat is not doable except by retaining all
> > > matches/targets (or at least some of them).
> > 
> > We'll provide a translation which means that the returns the closest
> > approximation to what they need.
> > 
> > That will not save them from reading the new documentation and
> > familiarizing with the new framework and tools. But we'll relieve the
> > pain of migration in some way.
> > 
> > As I said, the only way to get people moving forward is to provide
> > good reasons to learn the new tool and start using it.
> 
> I think we already have pretty good reasons, and they soon will get a lot
> stronger with concatenations and generic state keeping.

Agreed, the only way to get users moving forward is through features.