On Tue, Aug 26, 2014 at 03:47:06PM +0200, Pablo Neira Ayuso wrote: > On Tue, Aug 26, 2014 at 02:30:30PM +0100, Patrick McHardy wrote: > > >> - add a generation ID to the ruleset > > >> - dump the entire ruleset > > >> - generate delete commands for each existing rule/chain/set... > > >> - generate add commands for each new rule/chain/set... > > >> - send the entire thing to the kernel, including the generation ID > > >> - if the generation ID doesn't match, meaning the ruleset has changed > > >> since the last dump, return an error to userspace, retry > > > > > >The approach in my patchset is different: > > > > > >- generate a delete command that will flush all the previous ruleset > > >- generate add commands for each new rule/chain/set/tables > > >- send the batch to the kernel > > > > > >In this approach, we don't care about what is in the kernel previous > > >to the delete command. > > > > Sure, but as Pablo pointed out, it adds more code that needs to be maintained that isn't strictly neccessary. > > Oh, I probably didn't explain well myself. I'd like to see Arturo's > shortcut using _DELTABLE unless you have any concern with them :-). No concerns, was just trying to support your arguments :) Either way seems reasonable to me. > We still need that generation ID indeed to catch interferences between > two object dumps, I'll send you a patch proposal for this soon. Yep, we also need this for set transactions. I suppose we need generation IDs for each individual object type as well as AF-specific ones which change for any object change (table level doesn't work because sets are per AF). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
