Hi Phil, I have no better idea to cope with this forward compatibility requirements. On Thu, Aug 01, 2024 at 12:27:03AM +0200, Phil Sutter wrote: > Add a mechanism providing forward compatibility for the current and > future versions of iptables-nft (and all other nft-variants) by > annotating nftnl rules with the extensions they were created for. > > Upon nftnl rule parsing failure, warn about the situation and perform a > second attempt loading the respective compat extensions instead of the > native expressions which replace them. OK, so this is last resort to interpret the rule. > The foundational assumption is that libxtables extensions are stable > and thus the VM code created on their behalf does not need to be. OK, this requires xtables API becomes frozen forever. > Since nftnl rule userdata attributes are restricted to 255 bytes, the > implementation focusses on low memory consumption. Therefore, extensions > which remain in the rule as compat expressions are not also added to > userdata. In turn, extensions in userdata are annotated by start and end > expression number they are replacing. Also, the actual payload is > zipped using zlib. Binary layout is better than storing text in the userdata area. Is this zlib approach sufficient to cope with ebtables among extension? Maybe that one is excluded because it is using the set infrastructure since the beginning. I guess you already checked for worst case to make sure compression always allows to make things fit into 255 bytes? Thanks.
