On Mon, Nov 09, 2015 at 03:30:56PM +0000, Patrick McHardy wrote: > Hi Pablo, > > I'm wondering what the rational for the current cache update behaviour is. > The changelog states it is somehow related to the requested command, but > that doesn't seem to be true. > > Even "nft describe" fails with EPERM as user since the cache appears to be > initialized unconditionally, which is a bit unfortunate. Also I used to > test things parsing, evaluation and even netlink generation without actually > adding those rules as user, which does not work anymore. This might > be harder to get working again, but I'm not sure why we do a full > initialization anyways. The only thing that appears to be needed > are sets, and those only in some specific circumstances. To look up for the existing sets we need the existing tables and chains, they are essential part of the object hierarchy. So this is what we're currently dumping. In general, we need this for incremental updates, in scenarios where we have objects that are defined in kernelspace but userspace refers to them. As you said we can disable the cache in many cases, depending on the command or if the ruleset file starts by: flush ruleset but I have left this out as follow up work, I just wanted to make sure incremental updates where working, as well as the existing changes. nft describe should be easy to restore. Regarding inconditional check for table and chain, we have to make it from the evaluation step in sets, so leaving other objects without checking this seems inconsistent to me. Another side effect of this is better error reporting to the user. -- 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
