Hi Pablo,
I am not sure about what you mean. To me, we let the user playing
with the same exact statement they will use through nft tool.
After the parsing, nft generates and abstract syntax tree (see list of
statements and struct expr for instance). You can use that do build
the rule-set. You can easily build rules using that tree structure.
Sound relevant. Actually it might fix one of Jesper's use cases to
export such functions.
Btw on the cache feature, it will require some tweaks, since the way
libnftables keeps track of objects is not efficient currently:
- no specific data (void *) can be attached to any objects (easy fix)
- and table chain and rule have no better relationship on the object
model than the name.
For instance if you want to retrieve all the rules of one chain you
need to go through the whole rule list and compare the chain name of
each rule.
That's very easy to fix in the kernel. You only need a small patch for
nf_tables_api.c to dump only rules attached to one chain.
You got me wrong here. When handling a cache (which gets updated via
nftables notifications, after a full dump),
the point is to query it easily without the need of kernel calls. Like
nft_is_chain_present(my_chaine_name), things like that... (just a quick
example)
In fact, we should lower as much as possible the kernel calls.
Currently, the way libnftables stores the objects is under performing.
As I said if you want to quickly retrieve all rules of 1 chain, you have
no other possibility right now go through the rule list and compare the
chain name.
Instead if it would be possible to add our own pointer in a chain (user
data then) we could add the rule list pointer in the chain. So all chain
objects would
own a pointer on their rule list. It's a q&d idea, we can solve it
another way.
And for tables and chain (mostly chains actually), we could store them
in a hash table: key as the name, object pointer as a value.
Some implementation details like that. Let's figure it out when
implementing the lib.
I am thinking of those as well:
NFT_FLAG_FOLLOW_LOCAL (default): will notice about the locally manipulated
rules events.
NFT_FLAG_FOLLOW_GLOBAL: will keep notice about the whole rule set event.
Look at existing netfilter libraries like libnftables. All features
should be set via some set/get API, so we won't have hard times to
introduce new tweak and features.
That as nothing to do with libnftables set/get stuff.
This is for the application notification. In short it tries to
answer this: Should it be notified for all nftables event or only
about own statements?
What I'm trying to explain is that all these tweaks and user
preferences should be done by set/get API similar to
setsockopt/getsockopt. Not as flags to the main nft_init function.
Still: libnftables does not do anything with netlink send/recv,
notifications, etc... this is not libnftables related.
For me libnftables is only a nlh parser/builder, and it does it very
well. Unless you have plans to broaden its features scope?
Anyway let's put aside such flags, let's fix the first thing first:
executing nft statement and handle notifications.
It will help figuring out advanced features then.
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
