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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <m2wmtt4mqo.fsf@gmail.com>
Date: Mon, 04 Dec 2023 22:38:23 +0000
From: Donald Hunter <donald.hunter@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
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

Jakub Kicinski <kuba@...nel.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ