On Thu, Jun 20, 2013 at 01:36:00PM +0300, Tomasz Bursztyka wrote:
> 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.
We could instead of using NLA_RULE_HANDLE for the position add a new
attribute NLA_RULE_POSITION and use that both for creating rules and
for notifications. It would always be set and contain the handle of
the rule preceeding the new rule (for NLM_F_APPEND) or the one
following it (for !NLM_F_APPEND).
--
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
