Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > This is bad, but I do not know if we can change things to make > > nft_audit NOT do that. Hence add a new workaround patch that > > inflates the length based on the number of set elements in the > > container structure. > > It actually shows the number of entries that have been updated, right? > > Before this series, there was a 1:1 mapping between transaction and > objects so it was easier to infer it from the number of transaction > objects. Yes, but... for element add (but not create), we used to not do anything (no-op), so we did not allocate a new transaction and pretend request did not exist. Now we can enter update path, so we do allocate a transaction, hence, audit record changes. What if we add an internal special-case 'flush' op in the future? It will break, and the workaround added in this series needs to be extended. Same for an other change that could elide a transaction request, or, add expand something to multiple ones (as flush currently does). Its doesn't *break* audit, but it changes the output.
