On Thu, Mar 07, 2024 at 04:10:05PM +0100, Florian Westphal wrote: > Phil Sutter <phil@xxxxxx> wrote: > > > Problem is that the json input parser does cmd_add at the earliest opportunity. > > > > > > For a simple input file defining a table, set, set element and chain, we get > > > following transaction: > > > * add table > > > * add set > > > * add setelem > > > * add chain > > > > > > This is rejected by the kernel, because the set element references a chain > > > that does (not yet) exist. > > > > > > Normal input parser only allocates a CMD_ADD request for the table. > > > > > > Rest of the transactional commands are created much later, via nft_cmd_expand(), > > > which walks "struct table" and then creates the needed CMD_ADD for the objects > > > owned by that table. > > > > JSON parser simply does not support nested syntax, like, for instance: > > You mean, WONTFIX? Fine with me. Not quite, I see the problem you're trying to solve in patch 5. Sorting elements in the JSON "nftables" array properly for later insertion may become a non-trivial task given how maps and rules may refer to chains. So IIUC, JSON parser will now collapse all new ruleset items into a tree and use the existing nft_cmd_expand() to split things up again. This may impose significant overhead depending on input data (bogus/OpenShift use cases involving many chains maybe) on one hand, on the other might allow for overhead elimination in other cases (e.g. long lists of 'add element' commands for different sets in alternating fashion). We may want to do this for standard syntax as well if the benefits outweigh the downsides. Thus generalize the JSON-specific helpers you wrote for use within bison parser, too? An alternative might be to reorder code in table_print_json_full(), copying what nft_cmd_expand() does for CMD_OBJ_TABLE. AIUI, it should solve the current issue of failing 'nft -j list ruleset | nft -j -f -' for special cases. Cheers, Phil
