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

Message-ID: <ZdXxDZIAM5iLlO55@nanopsycho>
Date: Wed, 21 Feb 2024 13:48:13 +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 03:10:04AM CET, kuba@...nel.org wrote:
>On Tue, 20 Feb 2024 08:31:23 +0100 Jiri Pirko wrote:
>> >The "type agnostic" / generic style of devlink params and fmsg
>> >are contrary to YNL's direction and goals. YNL abstracts parsing  
>> 
>> True, but that's what we have. Similar to what we have in TC where
>> sub-messages are present, that is also against ynl's direction and
>> goals.
>
>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?