Re: [RFC PATCH 0/1] add insert after to nf_tables

[Patrick McHardy <kaber@trash.net>]

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).