Re: ynl - mutiple policies for one nested attr used in multiple cmds

[Jiri Pirko <jiri@resnulli.us>]

Fri, Aug 18, 2023 at 10:24:47PM CEST, kuba@kernel.org wrote:
>On Fri, 18 Aug 2023 20:11:16 +0200 Jiri Pirko wrote:
>> Okay, you don't have good solution, do you have at least the least bad
>> one? :)
>
>I was pondering this for the recent pp work:
>https://lore.kernel.org/all/20230816234303.3786178-13-kuba@kernel.org/
>search for NL_SET_ERR_MSG_ATTR.
>
>I ended up hand-rejecting the attrs which I didn't want.
>It's not great because the policy (netdev_page_pool_info_nl_policy)
>is shared so if someone adds stuff there they'll need to know
>to update all the rejects :[
>
>I guess a better way to code up the same idea would be to check if tb[]
>is NULL outside of expected attrs.

The problem is that with devlink, there no nostrict parsing. So the
like-to-be-ignored attrs if passed might error out during validation.

>
>Option #2 is to not use the auto-generated policy, and write the policy
>by hand in the kernel with the right members.

I'll go with this option for now I think.

>
>Option #3 is to add support for this to the YAML. With the existing
>concepts we would have to redefine all levels as subsets, and then
>we can override nested-attributes. A lot of typing. The YAML is really
>just a slightly decorated version of the policy tables. The policy
>tables in this case have to be separate.

Yeah. But eventually, I think this would be needed anyway to make yaml
to handle all the cases. Relying on the developer to do option #1 or #2
kinda defeats the inital yaml goal to avoid people mistakes, I think.