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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZddKHCNy5pEVnQKL@nanopsycho>
Date: Thu, 22 Feb 2024 14:20:28 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
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

Wed, Feb 21, 2024 at 07:45:05PM CET, kuba@...nel.org wrote:
>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.

Okay, will keep it in the cupboard for now. I would definitelly love to
get the devlink.yaml complete. Next step is to generate the uapi header
from it replacing the existing one.