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]

Date: Tue, 20 Feb 2024 08:31:23 +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

Mon, Feb 19, 2024 at 11:52:04PM CET, kuba@...nel.org wrote:
>On Mon, 19 Feb 2024 18:25:22 +0100 Jiri Pirko wrote:
>> For devlink param, param-value-data attr is used by kernel to fill
>> different attribute type according to param-type attribute value.
>> 
>> Currently the sub-message feature allows spec to embed custom message
>> selected by another attribute. The sub-message is then nested inside the
>> attr of sub-message type.
>> 
>> Benefit from the sub-message feature and extend it. Introduce
>> attribute-replace spec flag by which the spec indicates that ynl should
>> consider sub-message as not nested in the original attribute, but rather
>> to consider the original attribute as the sub-message right away.
>
>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.

>and typing using external spec. devlink params and fmsg go in a
>different direction where all information is carried by netlink values
>and netlink typing is just to create "JSON-like" formatting.

Only fmsg, not params.

>These are incompatible ideas, and combining these two abstractions
>in one library provides little value - devlink CLI already has an
>implementation for fmsg and params. YNL doesn't have to cover
>everything.

True. In this patchset, I'm just using the existing sub-message
infrastructure with a bit of extension. The json-like thing of fmsg is
ignored, I don't try to reconstruct json from netlink message of fmsg.