Hi Pablo,
Hum, how?
The handle it will get from the notification is the handle of the
newly created rule, not the one used to identify the rule for
insertion.
That's right. I don't come with any other way to make it rather than
adding a new attribute.
Yes, though it breaks the design logic of the current API, somehow.
I mean, attributes are currently reflecting the rule as it is, and are
used symmetrically in queries/replies.
Here what we need is a temporary extra attribute, or some sort, only
used for the notification.
Either via:
we don't add an element to enum nft_rule_attributes {}, instead we
create another enum for attributes only used on notification.
like enum nft_rule_extras_notifications_attributes {}
Or via (maybe better for nla policy way of working?):
Adding a nft_rule_attributes as NFTA_RULE_EXTRAS_NOTIFICATIONS as a
nested attribute
and then enum nft_rule_extras_notifications_attributes {} again, etc etc...
It's just a quick proposal, but my point here is to keep the API
semantically sane.
So it won't require extra guesses to understand how it's supposed to work
(as it is right now: it's a sane API, besides the lonely
NFT_RULE_F_COMMIT in its anonymous enum)
Maybe there is a better way, probably. But you get my point.
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
