Hi, On Fri, Oct 09, 2020 at 12:37:25PM +0200, Jozsef Kadlecsik wrote: [...] > I know lots of effort went into backward compatibility, this should be > included there too. Certainly doable. Some hacking turned into quite a mess, though: When restoring without '--noflush', a chain cache is needed - simply doable by treating NFT_CL_FAKE differently. Reacting upon a chain policy of '-' is easy, just lookup the existing chain's policy from cache and use that. Things then become ugly for not specified chains: 'flush_table' callback really deletes the table. So one has to gather the existing builtin chains first, check if their policy is non-default and restore those. If they don't exist though, one has to expect for them to occur when refreshing the transaction (due to concurrent ruleset change). So the batch jobs have to be created either way and just set to 'skip' if either table or chain doesn't exist or the policy is ACCEPT. If alternatively I decide to drop the table delete in 'flush_table', I need to decide whether a builtin chain should be deleted or not, based on its policy - which may change, so when refreshing transaction I would have to turn a chain delete job into a flush rules one. Not nice, so don't delete builtin chains in the first place. But the next obstacle comes with user-defined chains: Deleting the existing ones, no problem - cache is there. But when refreshing the transaction, new ones have to be expected, so new jobs created. The potential need to refresh a transaction is really causing head-aches and the simple approach of dropping the table helped quite a bit with that. Maybe I could implement some kernel bits to make things simpler, like "delete all non-base chains" or "create chain if not existing". But first I need more coffee. %) Cheers, Phil
