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: <20240220181004.639af931@kernel.org>
Date: Tue, 20 Feb 2024 18:10:04 -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 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.