On Thu, Aug 01, 2024 at 12:26:55AM +0200, Phil Sutter wrote:
> Time to abandon earlier attempts at providing compatibility for old
> binaries, choose the next best option which is not relying upon any
> kernel changes.
>
> Basically, all extensions replaced by native bytecode are appended to
> rule userdata so when nftnl rule parsing code fails, it may retry
> omitting all these expressions and restoring an extension from userdata
> instead.
>
> The idea behind this is that extensions are stable which relieves native
> bytecode from being the same. With this series in place, one may
> (re-)start converting extensions into native nftables bytecode again.
>
> For now, appending compat extensions is always active. Keeping it
> disabled by default and enabling via commandline flag or (simpler) env
> variable might make sense (I haven't tested performance yet). The
> parsing component will take action only if standard rule parsing fails,
> so no need to manually enable this IMO.
>
> The actual implementation sits in patch 8, the preceeding ones are
> (mostly) preparation.
>
> To forcibly exercise the fallback rule parsing code, compile with
> CFLAGS='-DDEBUG_COMPAT_EXT=1'.
>
> Phil Sutter (8):
> ebtables: Zero freed pointers in ebt_cs_clean()
> ebtables: Introduce nft_bridge_init_cs()
> nft: Reduce overhead in nft_rule_find()
> nft: ruleparse: Drop 'iter' variable in
> nft_rule_to_iptables_command_state
> nft: ruleparse: Introduce nft_parse_rule_expr()
> nft: __add_{match,target}() can't fail
> nft: Introduce UDATA_TYPE_COMPAT_EXT
> nft: Support compat extensions in rule userdata
Applied patches 1-4 as they are independent from the actual compat
extensions feature.
