On Fri, 2019-04-26 at 21:37 +0200, Johannes Berg wrote:
> You're now thinking of the "policy ID" I assigned for the wire format as
> the object ID, but really that's not what it is. The object ID that
> you're looking for is the attribute type of the nested attribute.
>
> So if you have
>
> struct nla_policy nested_policy[...] = { ... };
>
> struct nla_policy policy[...] = {
> [MY_ATTR] = NLA_POLICY_NESTED(nested_policy),
> };
>
So if we extend this, say like this:
struct nla_policy policy[...] = {
[MY_ATTR] = NLA_POLICY_NESTED(nested_policy),
[MY_OTHER_ATTR] = NLA_POLICY_NESTED(nested_policy),
};
then you could perhaps argue that having an object ID makes sense, and
assigning the same object ID to MY_ATTR and MY_OTHER_ATTR would make
sense?
Of course, my could would assign this the same (temporary) policy ID,
but there can be no reliance on the policy ID beyond what's needed at
runtime to map the attribute to the nested policy.
You still see at runtime that these have the same policy (since they
have the same policy ID), but at the same time presumably there was a
reason to have MY_ATTR and MY_OTHER_ATTR, so perhaps the semantics are
different even if the attributes are the same, as could perhaps be
expected if you have a SET and a CLEAR attribute (MY_ATTR and
MY_OTHER_ATTR respectively) and the contents you give has the same
policy, but different logic?
Basically, I just didn't consider this case to be significant enough to
manually and assign stable IDs of some sort, when we already have them
in the form of the attribute type.
johannes
