On Wed, Jan 17, 2018 at 07:56:30PM +0100, Phil Sutter wrote: > On Wed, Jan 17, 2018 at 07:45:04PM +0100, Pablo Neira Ayuso wrote: > [...] > > > On Wed, Jan 17, 2018 at 01:50:26PM +0100, Pablo Neira Ayuso wrote: > > > > On Wed, Jan 17, 2018 at 01:44:06PM +0100, Pablo Neira Ayuso wrote: > > > > > On Wed, Jan 17, 2018 at 12:51:40PM +0100, Phil Sutter wrote: > > > > [...] > > > > > > > > > > > * There is quite some code-duplication involved given that this > > > > > > introduces an alternative function for almost any function in the > > > > > > affected code path. > > > > > > > > > > You mean, a new callback for each expr/datatype? We should not expose > > > > > bitwise/byteorder and such, it's too low level. > > > > > > > > I'd rather see you map the abstract syntax tree that is represented > > > > through parser_bison.y to your json representation. I think this patch > > > > is mapping the tree that we obtain after the evaluation phase, which > > > > comes with low level expressions such as bitwise/byteorder. > > > > > > I don't get your point here, either: Not sure what this has to do with > > > parser_bison.y - my patch handles output only for now, I didn't bother > > > with input yet. Or am I on the completely wrong track now? > > > > Sorry, I was refering about the input support. > > Ah, I see. For input, I did consider using bison BTW, but doubt it will > lead to less code than implementing everything with libjansson. And yes, > this will then be on the same level as parser_bison.y, so what is parsed > will then be fed to cmd_evaluate(). Not asking to build a json parser in bison. I mean, json layout should result in an abstract syntax tree, that is exactly what nft bison would generate. Does this clarify? -- 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
