From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com, jacob.e.keller@intel.com,
swarupkotikalapudi@gmail.com, donald.hunter@gmail.com,
sdf@google.com, lorenzo@kernel.org,
alessandromarcolini99@gmail.com
Subject: Re: [patch net-next 06/13] tools: ynl: introduce attribute-replace for sub-message
Date: Tue, 20 Feb 2024 18:10:04 -0800 [thread overview]
Message-ID: <20240220181004.639af931@kernel.org> (raw)
In-Reply-To: <ZdRVS6mHLBQVwSMN@nanopsycho>
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.
next prev parent reply other threads:[~2024-02-21 2:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 17:25 [patch net-next 00/13] netlink: specs: devlink: add the rest of missing attribute definitions Jiri Pirko
2024-02-19 17:25 ` [patch net-next 01/13] tools: ynl: allow user to specify flag attr with bool values Jiri Pirko
2024-02-19 20:42 ` Jakub Kicinski
2024-02-20 7:24 ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 02/13] tools: ynl: process all scalar types encoding in single elif statement Jiri Pirko
2024-02-19 17:25 ` [patch net-next 03/13] tools: ynl: allow user to pass enum string instead of scalar value Jiri Pirko
2024-02-19 20:49 ` Jakub Kicinski
2024-02-20 7:25 ` Jiri Pirko
2024-02-21 1:55 ` Jakub Kicinski
2024-02-21 14:31 ` Jiri Pirko
2024-02-19 20:51 ` Jakub Kicinski
2024-02-20 7:27 ` Jiri Pirko
2024-02-21 1:59 ` Jakub Kicinski
2024-02-21 11:40 ` Donald Hunter
2024-02-19 17:25 ` [patch net-next 04/13] netlink: specs: allow sub-messages in genetlink-legacy Jiri Pirko
2024-02-19 20:51 ` Jakub Kicinski
2024-02-20 7:28 ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 05/13] tools: ynl: allow attr in a subset to be of a different type Jiri Pirko
2024-02-19 17:25 ` [patch net-next 06/13] tools: ynl: introduce attribute-replace for sub-message Jiri Pirko
2024-02-19 22:52 ` Jakub Kicinski
2024-02-20 7:31 ` Jiri Pirko
2024-02-21 2:10 ` Jakub Kicinski [this message]
2024-02-21 12:48 ` Jiri Pirko
2024-02-21 18:45 ` Jakub Kicinski
2024-02-22 13:20 ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 07/13] tools: ynl: add support for list in nested attribute Jiri Pirko
2024-02-19 17:25 ` [patch net-next 08/13] netlink: specs: devlink: add enum for param-type attribute values Jiri Pirko
2024-02-19 17:25 ` [patch net-next 09/13] netlink: specs: devlink: add missing param attribute definitions Jiri Pirko
2024-02-19 17:26 ` [patch net-next 10/13] netlink: specs: devlink: treat dl-fmsg attribute as list Jiri Pirko
2024-02-19 17:26 ` [patch net-next 11/13] netlink: specs: devlink: add enum for fmsg-obj-value-type attribute values Jiri Pirko
2024-02-19 17:26 ` [patch net-next 12/13] netlink: specs: devlink: add missing fmsg-obj-value-data attribute definitions Jiri Pirko
2024-02-19 17:26 ` [patch net-next 13/13] netlink: specs: devlink: add missing nested devlink definitions Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240220181004.639af931@kernel.org \
--to=kuba@kernel.org \
--cc=alessandromarcolini99@gmail.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=swarupkotikalapudi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).