netdev - Re: [patch net-next 06/13] tools: ynl: introduce attribute-replace for sub-message

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240221104505.23938b01@kernel.org>
Date: Wed, 21 Feb 2024 10:45:05 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
 edumazet@...gle.com, jacob.e.keller@...el.com,
 swarupkotikalapudi@...il.com, donald.hunter@...il.com, sdf@...gle.com,
 lorenzo@...nel.org, alessandromarcolini99@...il.com
Subject: Re: [patch net-next 06/13] tools: ynl: introduce attribute-replace
 for sub-message

On Wed, 21 Feb 2024 13:48:13 +0100 Jiri Pirko wrote:
> >But TC and ip-link are raw netlink, meaning genetlink-legacy remains
> >fairly straightforward. BTW since we currently have full parity in C
> >code gen adding this series will break build for tools/net/ynl.
> >
> >Plus ip-link is a really high value target. I had been pondering how 
> >to solve it myself. There's probably a hundred different implementations
> >out there of container management systems which spawn veths using odd
> >hacks because "netlink is scary". Once I find the time to finish
> >rtnetlink codegen we can replace all  the unholy libbpf netlink hacks
> >with ynl, too.
> >
> >So at this stage I'd really like to focus YNL on language coverage
> >(adding more codegens), packaging and usability polish, not extending
> >the spec definitions to cover not-so-often used corner cases.
> >Especially those which will barely benefit because they are in
> >themselves built to be an abstraction.  
> 
> That leaves devlink.yaml incomplete, which I'm not happy about. It is a
> legacy, it should be covered by genetlink-legacy I believe.
> 
> To undestand you correctly, should I wait until codegen for raw netlink
> is done and then to rebase-repost this? Or do you say this will never be
> acceptable?

It'd definitely not acceptable before the rtnetlink C codegen is
complete, and at least two other code gens for genetlink-legacy.
At that point we can reconsider complicating the schema further.