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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231129094943.13f1ae0c@kernel.org>
Date: Wed, 29 Nov 2023 09:49:43 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Donald Hunter <donald.hunter@...il.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jonathan
 Corbet <corbet@....net>, linux-doc@...r.kernel.org,
 donald.hunter@...hat.com
Subject: Re: [RFC PATCH net-next v1 0/6] tools/net/ynl: Add dynamic selector
 for options attrs

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.