[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c91beb0-8b25-0d2f-87b3-3ada27e51e73@intel.com>
Date: Mon, 5 Oct 2020 14:52:32 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Johannes Berg <johannes@...solutions.net>,
Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, kernel-team@...com,
jiri@...nulli.us, andrew@...n.ch, mkubecek@...e.cz
Subject: Re: [PATCH net-next 1/6] ethtool: wire up get policies to ops
On 10/5/2020 12:33 PM, Johannes Berg wrote:
> On Mon, 2020-10-05 at 12:31 -0700, Jakub Kicinski wrote:
>
>> Yea, I think we're both confused. Agreed with the above.
>>
>> Are you suggesting:
>>
>> const struct nla_policy policy[/* no size */] = {
>> [HEADER] = NLA_POLICY(...)
>> [OTHER_ATTR] = NLA_POLICY(...)
>> };
>>
>> extern const struct nla_policy policy[/* no size */];
>>
>> op = {
>> .policy = policy,
>> .max_attr = OTHER_ATTR,
>> }
>
> No, that'd be awkward, for the reason you stated below.
>
>> What I'm saying is that my preference would be:
>>
>> const struct nla_policy policy[OTHER_ATTR + 1] = {
>> [HEADER] = NLA_POLICY(...)
>> [OTHER_ATTR] = NLA_POLICY(...)
>> };
>>
>> extern const struct nla_policy policy[OTHER_ATTR + 1];
>>
>> op = {
>> .policy = policy,
>> .max_attr = ARRAY_SIZE(policy) - 1,
>> }
>>
>> Since it's harder to forget to update the op (you don't have to update
>> op, and compiler will complain about the extern out of sync).
>
> Yeah.
>
> I was thinking the third way ;-)
>
> const struct nla_policy policy[] = {
> [HEADER] = NLA_POLICY(...)
> [OTHER_ATTR] = NLA_POLICY(...)
> };
>
> op = {
> .policy = policy,
> .maxattr = ARRAY_SIZE(policy) - 1,
> };
>
>
> Now you can freely add any attributes, and, due to strict validation,
> anything not specified in the policy will be rejected, whether by being
> out of range (> maxattr) or not specified (NLA_UNSPEC).
>
> johannes
>
This is what I was thinking of as well.
Powered by blists - more mailing lists