netdev - Re: [PATCH net-next v1 02/12] tools/net/ynl: Support sub-messages in nested attribute spaces

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: <20240129173259.1a2451df@kernel.org>
Date: Mon, 29 Jan 2024 17:32:59 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Donald Hunter <donald.hunter@...il.com>
Cc: Alessandro Marcolini <alessandromarcolini99@...il.com>,
 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>, Breno Leitao <leitao@...ian.org>, Jiri Pirko
 <jiri@...nulli.us>, donald.hunter@...hat.com
Subject: Re: [PATCH net-next v1 02/12] tools/net/ynl: Support sub-messages
 in nested attribute spaces

On Sun, 28 Jan 2024 19:36:29 +0000 Donald Hunter wrote:
> > from collections import ChainMap
> >
> > class LevelChainMap(ChainMap):
> >     def __getitem__(self, key):
> >         for mapping in self.maps:
> >             try:
> >                 return mapping[key], self.maps[::-1].index(mapping)
> >             except KeyError:
> >                 pass
> >         return self.__missing__(key)
> >
> >     def get(self, key, default=None, level=None):
> >         val, lvl = self[key] if key in self else (default, None)
> >         if level:
> >             if lvl != level:
> >                 raise Exception("Level mismatch")
> >         return val, lvl
> >
> > # example usage
> > c = LevelChainMap({'a':1}, {'inner':{'a':1}}, {'outer': {'inner':{'a':1}}})
> > print(c.get('a', level=2))
> > print(c.get('a', level=1)) #raise err
> >
> > This will leave the spec as it is and will require small changes.
> >
> > What do you think?  
> 
> The more I think about it, the more I agree that using path-like syntax
> in the selector is overkill. It makes sense to resolve the selector
> level from the spec and then directly access the mappings from the
> correct scope level.

Plus if we resolve from the spec that's easily reusable in C / C++ 
code gen :)