On 10.04, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Thu, Apr 09, 2015 at 10:51:35PM +0200, Florian Westphal wrote: > > > Why would I want to re-write a working nft+compat ruleset to one > > > that only uses native expressions? > > > > The fact is that we cannot push users to use nf_tables, but we can > > provide good reasons to adopt the native replacements and tools to > > migrate easily. > > I think dictionaries are a pretty good reason :-) > > > > 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' ... ? > > 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). That's my biggest fear as well. I very much prefer to selectively add what people are actually requesting or what obviously makes sense. That way we at least know that something is needed and why. -- 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
