Re: [PATCH net-next v1 6/6] doc/netlink/specs: Add a spec for tc

[Donald Hunter <donald.hunter@gmail.com>]

Jakub Kicinski <kuba@kernel.org> writes:

> On Mon, 04 Dec 2023 16:27:24 +0000 Donald Hunter wrote:
>> > Ugh. Meaning the selector is at a "previous" level of nesting?
>>
>> That's right. I wonder if we should use a relative syntax like "../kind"
>> for the selector. Will either need to pass the known attrs to nest
>> parsing, or pass a resolver instead?
>
> ../kind is my first thought, too.
>
> But on reflection I reckon it may make the codegen and Python parser
> quite a bit more complex. :S

That was my main concern with it too.

Another thought I had was to explicitly mark attrs that get used as
selector keys, but I don't think that actually buys us anything.

> Passing in known selector attrs to nests sounds good. Assuming we never
> have to do something like: "../other-nest/attr".
> Or perhaps in that case we can support passing in nested attrs, just
> not backtracking? Backtracking is the hard part, really. Yeah, that
> sounds simplest, at least at the "thought exercise level" :)
>
> What would "resolver" look like?

I was thinking a resolver would be a class with a single lookup method
that internally holds attributes from the current scope and has a parent
it can delegate to. It would try to resolve e.g. "kind" in current scope
then, on failure, delegate to its parent. When recursing to decode a
submsg, create a new resolver with the current one as its parent.

If we did it this way, there'd be no need for "../kind".

> BTW how do we deal with ordering. Do we require that selector attr
> must be present in the message before the submsg? I think in practice
> is should always be the case, but we should document that.

The selector attr is de-facto present in the message before it is
needed, both at the same level and for sub messages. So, yeah, I think
we require this and agreed we should document it. I will do that in
the next revision.

From what I have seen so far, selector attrs are at same level or at
root level, but I'm not confident that will hold true for all of the raw
families.