Hi Pablo, On Thu, Dec 07, 2017 at 01:05:45AM +0100, Pablo Neira Ayuso wrote: > On Tue, Dec 05, 2017 at 02:43:17PM +0100, Phil Sutter wrote: [...] > > After tweaking the parser a bit, I can use it now to parse just a > > set_list_member_expr and use the struct expr it returns. This made it > > possible to create the desired struct cmd in above function without > > having to invoke the parser there. > > > > Exercising this refining consequently should allow to reach arbitrary > > levels of granularity. For instance, one could stop at statement level, > > i.e. statements are created using a string representation. Or one could > > go down to expression level, and statements are created using one or two > > expressions (depending on whether it is relational or not). Of course > > this means the library will eventually become as complicated as the > > parser itself, not necessarily a good thing. > > Yes, and we'll expose all internal representation details, that we > will need to maintain forever if we don't want to break backward. Not necessarily. I had this in mind when declaring 'struct nft_table' instead of reusing 'struct table'. :) The parser defines the grammar, the library would just follow it. So if a given internal change complies with the old grammar, it should comply with the library as well. Though this is quite theoretical, of course. Let's take relational expressions as simple example: In bison, we define 'expr op rhs_expr'. An equivalent library function could be: | struct nft_expr *nft_relational_new(struct nft_expr *, | enum rel_ops, | struct nft_expr *); What is allowed in rhs_expr may change internally without breaking ABI or the parser-defined language. Can you think of a problematic situation? My view is probably a bit rose-coloured. ;) > > On the other hand, having an abstract representation for set elements is > > quite convenient - their string representations might differ (take e.g. > > "22" vs. "ssh") so strcmp() is not sufficient to compare them. > > > > I hope this allows you to get an idea of how I imagine extended API > > although certainly details are missing here. What do you think about it? > > Are you fine with the general concept so we can discuss details or do > > you see a fundamental problem with it? > > OK, my understanding is that you would like to operate with some > native library object representation. > > Most objects (table, chain...) are easy to represent, as you > mentioned. Rules are the most complex ones internally, but you can > probably abstract a simplified representation that suits well for your > usecases, e.g expose them in an iptables like representation - > something like adding matches and actions - Obviously, this needs to > allow to take sets as input, eg. > > int meta_match_immediate(struct nft_rule *r, enum nft_meta_type, void *data); > int meta_match_set(struct nft_rule *r, enum nft_meta_type, struct nft_set *set); > > meta_match_immediate() adds a meta + cmp to the rule, to compare for > an immediate value. meta_match_set() adds meta + lookup. Yes, that sounds good. I had something like this in mind: | struct nft_stmt *nft_meta_match_immediate(enum nft_meta_type, void *data); | int nft_rule_append_stmt(struct nft_rule *r, struct nft_stmt *stmt); The obvious problem is that at the time that meta match is created, there is no context information. So the second function would have to do that. I am not sure if this kind of context evaluation works in any case. E.g. set elements are interpreted depending on the set they are added to. To my surprise, that wasn't really an issue - the parser interprets it as constant symbol, when evaluating the expression as part of adding it to the set it is resolved properly. This might not work in any case, though. > A list of use-cases, for the third party application, would be good to > have to design this API. OK, I'll take firewalld as an example and come up with a number of use-cases which would help there. Thanks, Phil -- 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
