Re: [RFC libnftnl/nft 0/5] nftables: indicate presence of unsupported netlink attributes

[Phil Sutter <phil@nwl.cc>]

On Wed, Oct 16, 2024 at 09:28:46PM +0200, Jan Engelhardt wrote:
> 
> On Wednesday 2024-10-16 19:07, Phil Sutter wrote:
> >On Mon, Oct 07, 2024 at 11:49:33AM +0200, Florian Westphal wrote:
> >[...]
> >> Extend libnftnl to also make an annotation when a known expression has
> >> an unknown attribute included in the dump, then extend nftables to also
> >> display this to the user.
> >
> >We must be careful with this and LIBVERSION updates. I'm looking at
> >libnftnl-1.2.0 which gained support for NFTA_TABLE_OWNER,
> >NFTA_SOCKET_LEVEL, etc. but did not update LIBVERSION at all - OK,
> >that's probably a bug. But there is also libnftnl-1.1.9 with similar
> >additions (NFTA_{DYNSET,SET,SET_ELEM}_EXPRESSIONS) and a LIBVERSION
> >update in the compatible range (15:0:4 -> 16:0:5).
> 
> From 1.1.8 to 1.1.9, there were a bunch of function additions:
> 
> +void nftnl_expr_add_expr(struct nftnl_expr *expr, uint32_t type, struct nftnl_expr *e);
> +int nftnl_expr_expr_foreach(const struct nftnl_expr *e,
> +                           int (*cb)(struct nftnl_expr *e, void *data),
> +                           void *data);
> 
> No such modifications (of this kind, or any stronger kind) were made between
> 1.1.9 to 1.2.0, hence there was no LIBVERSION update.

Ah, you're right! No libnftnl.map update, so no newly exported symbols.
The ABI must be identical between the two and thus LIBVERSION remaining
the same is correct.

> Expanding the enum{} generally does not change the ABI unless the underlying
> type changes (which it did not in this instance).

I got confused by the added nftnl object attributes, but the data
structures are hidden for a reason and the getter/setter mechanism
allows for exactly these changes to happen under the surface.

Thanks for clarifying!