Hi! On Wed, Jun 12, 2024 at 09:50:13AM +0200, Florian Westphal wrote: > "nft list ruleset" currently omits things it does not understand > and that it cannot represent in any other way. > > This includes: > 1. expression is unknown > 2. expression is known (e.g. "cmp"), but attr contains unexpected value > 3. expression is known but there is an unknown netlink attr contained in > the dump > > If backend (libnftl) could mark expressions as incomplete (from .parse > callbacks?), it would be then possible for the frontend (nft) to document > this, e.g. by adding something like "# unknown attributes", or similar. > > This is mainly needed for container environments, where host environment > might be using a lot older version than what is used by a specific > container image. ACK, we'll certainly end up in a similar situation as with iptables-nft so doing nothing is not an option. > Related problem: entity that is using the raw netlink interface, it > that case libnftnl might be able to parse everything but nft could > lack the ability to properly print this. > > If noone has any objections, I would place this on my todo list and > start with adding to libnftnl the needed "expression is incomplete" > marking by extending the .parse callbacks. The JSON interface prefixes dumps by a metainfo object which holds nft version number and a schema version (still "1"). Introducing a similar "bytecode versioning" cached in and dumped by kernel space might be a quick way to enable a current nft tool to detect a bytecode from the future, assuming that we'll also take care and increment that version when things change. OTOH, considering compatibility (or testing for it somehow) of a given bytecode change may be much more tedious than a practical approach of trying to parse and using a defined exit when failing. Cheers, Phil
