Hi Jesper,
>- either via proposing low level functions requesting the cache as you
>propose (and we probably should)
I'm a little worried about your idea of implementing a cache.
It reminds me of the current libliptc (IPtables Cache) library, which
caused a lot of annoying issues in the past.
I know, you said we can use the notification system to keep the cache
up-to-date, but just have a bad feeling about introducing a cache
layer...
It should be indeed much easier and reliable to maintain a cache with
nftables api.
But you are right: not all usage might require this. That's why I
thought about NFT_FLAG_FOLLOW_* flags
One could limit the "caching" towards only application
rules/chain/tables (if any), and other one would keep track of everything.
>- and/or when using nft_execute_statement() it would check if it already
>exist - or not, if it's a delete statement -
>by itself, hiding the details to the dev and raising a success relevantly.
So, your are saying that a nft_execute_statement() that creates a rule
sound return a "false" indication if the rule already exists?
I would really prefer a real "test/query" operation, but I guess we
should extend the kernel API to support this, so we don't need a cache
infrastructure for this.
I don't know if such existence test should be part of kernel API rather
than in user land since when manipulating
you need anyway a dump of the rule set.
But about nft_execute_statement(), it's not really a false indication:
you want to inject a rule which already exist, so it's fine.
Or we could handle it so it return an error like -EALREADY if it's
preferable.
Br,
Tomasz
--
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
