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@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
