netdev - Re: [RFC net-next v1] tools: ynl: Add an strace rendering mode to ynl-gen

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: Thu, 15 Jun 2023 19:19:12 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Donald Hunter <donald.hunter@...il.com>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	donald.hunter@...hat.com
Subject: Re: [RFC net-next v1] tools: ynl: Add an strace rendering mode to
 ynl-gen

On Thu, Jun 15, 2023 at 04:13:36PM +0100, Donald Hunter wrote:
> Add --mode strace to ynl-gen-c.py to generate source files for strace
> that teach it to understand how to decode genetlink messages defined
> in the spec. I successfully used this to add openvswitch message
> decoding to strace as I described in:
> 
> https://donaldh.wtf/2023/06/teaching-strace-new-tricks/
> 
> It successfully generated ovs_datapath and ovs_vport but ovs_flow
> needed manual fixes to fix code ordering and forward declarations.
> 
> Limitations:
> 
> - Uses a crude mechanism to try and emit functions in the right order
>   which fails for ovs_flow
> - Outputs all strace sources to stdout or a single file
> - Does not use the right semantic strace decoders for e.g. IP or MAC
>   addresses because there is no schema information to say what the
>   domain type is.
> 
> This seems like a useful tool to have as part of the ynl suite since
> it lowers the cost of getting good strace support for new netlink
> families. But I realise that the generated format is dependent on an
> out of tree project. If there is interest in having this in-tree then
> I can clean it up and address some of the limitations before
> submission.
> 
> Signed-off-by: Donald Hunter <donald.hunter@...il.com>

...

> +    # C code for attibute set decoders

Hi Donald,

a minor nit from my side: attibute -> attribute