Re: [RFC PATCH net-next v1 0/6] tools/net/ynl: Add dynamic selector for options attrs

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 29 Nov 2023 16:58:57 +0000 Donald Hunter wrote:
> rt_link shares attribute-sets between different kinds of link so I think
> that rules out putting the key on the attribute-set. I think we may also
> see reuse across stats attribute sets in tc.
> 
> FWIW I initially considered avoiding a selector list by using a template
> to generate the attribute set name, but that broke pretty quickly.

Ah :(

> It seems reasonable to pull the selector list out of line because
> they do get big, e.g. over 100 lines for tc "options".
> 
> My preference is 1, probably including a fallback to "binary" if there
> is no selector match.

Are there any "nests" that need a real binary type? An actual byte
array? Or are these all structs? If the latter then fixed-header
covers it.

> I think that once you have broken out to a sub-message, they're no
> longer "nested-attributes" and we should maybe reuse "attribute-set".

Good point.

> I don't think we can reuse "sub-type" because the schema for it is the
> set of netlink type names, not a free string. Maybe we add "sub-message"
> instead?

Sounds good.

> So how about this:
> 
> attribute-sets:
>   -
>     name: outside-attrs
>     attributes:
>       ...
>       -
>          name: kind
>          type: string
>       -
>          name: options
>          type: sub-message
>          sub-message: inside-msg
>          selector: kind
>     ...
>   -
>     name: inside-attrs:
>     attributes:
>       ...
> 
> sub-messages:
>   -
>     name: inside-msg
>     formats:
>       -
>         value: some-value
>         fixed-header: struct-name
>       -
>         value: other-value
>         fixed-header: struct-name-two
>         attribute-set: inside-attrs
>       -
>         value: another-one
>         attribute-set: inside-attrs
>   -
>     name: different-inside-msg
>     ...
> 
> operations:
>   ...

LG!

> I cannot think of a better name than "formats" so happy to go with that.

Or maybe "variants" ?

> Did you want an explicit "list:" in the yaml schema?

You mean instead of the "formats" or in addition somewhere?
Under sub-messages?

The "formats" is basically a "list", just feels less artificial
to call it something else than "list". No strong preference, tho.

If you mean under "sub-messages" - I can't think of any extra property
we may want to put there. So going directly to entries seems fine.