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.
