Hello Pablo, what do you think about this proposal? -- S pozdravem, David Fabian Cluster Design, s.r.o. Dne úterý 30. ledna 2018 12:05:48 CET, David Fabian napsal(a): > Hello Pablo, > > Dne pátek 26. ledna 2018 14:45:49 CET, Pablo Neira Ayuso napsal(a): > > 2) Probably even cleaner is to look at 'local' scopes like in bash. > > > > define local IP1 = 1.1.1.1 > > > > so the symbol is bound to this file - consider the content of a file > > determines a given scope. This can be also useful to the nested > > notation. > > > > 3) You rework your ruleset to use the notation with nesting :-). But I > > think 2) can be useful for both the flat and nested notation. > > > > I'm not asking you to do 2), but I would like to see how a patch that > > adds explicit scoping for the flat ruleset representation looks like. > > I know about scopes in the code but unfortunately as you said, the flat > notation only has a single scope. Since we are talking about analogy to > bash, bash allows me to redefine a variable in the same scope. Variables in > nftables feel more like constants which is not necessarily bad as it can > prevent some typos but is hard to work with in scripting as it's not that > flexible. > > From those options you listed I would strongly prefer to have an implicit > scope for each file included in the flat notation. That way, defining a > variable in one file would not collide with the same variable in a sibling > include. Variables from outer scopes would still be available in inner > scopes. For people that would want to have their "global" definitions in a > separate include, I would recommend creating a new keyword like global or > export that would tie a variable to the top-level scope and thus make it > available to everyone. I don't think that would be that hard to implement > and I may try to if we agree on it. > > Anyway there should definitely be a way to de-register (undefine) a variable > from a scope to prevent a misuse due to typos. > > By the way, can we restructure the FW using nesting and still be able to > retain all per-customer rules in a single file? Wouldn't that require us to > split prerouting, postrouting, forward and other rules to separate scopes/ > table definitions? That would be highly inconvenient. -- 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
