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

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]

Date: Mon, 4 Dec 2023 10:32:47 -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, Jacob Keller
 <jacob.e.keller@...el.com>, donald.hunter@...hat.com
Subject: Re: [PATCH net-next v1 6/6] doc/netlink/specs: Add a spec for tc

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

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?

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.