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: <20240219145204.48298295@kernel.org>
Date: Mon, 19 Feb 2024 14:52: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 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
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.
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ