From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
nicolas.dichtel@6wind.com, donald.hunter@gmail.com,
jiri@resnulli.us, sdf@google.com,
Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next v3 00/15] tools: ynl: stop using libmnl
Date: Tue, 27 Feb 2024 14:30:17 -0800 [thread overview]
Message-ID: <20240227223032.1835527-1-kuba@kernel.org> (raw)
There is no strong reason to stop using libmnl in ynl but there
are a few small ones which add up.
First (as I remembered immediately after hitting send on v1),
C++ compilers do not like the libmnl for_each macros.
I haven't tried it myself, but having all the code directly
in YNL makes it easier for folks porting to C++ to modify them
and/or make YNL more C++ friendly.
Second, we do much more advanced netlink level parsing in ynl
than libmnl so it's hard to say that libmnl abstracts much from us.
The fact that this series, removing the libmnl dependency, only
adds <300 LoC shows that code savings aren't huge.
OTOH when new types are added (e.g. auto-int) we need to add
compatibility to deal with older version of libmnl (in fact,
even tho patches have been sent months ago, auto-ints are still
not supported in libmnl.git).
Thrid, the dependency makes ynl less self contained, and harder
to vendor in. Whether vendoring libraries into projects is a good
idea is a separate discussion, nonetheless, people want to do it.
Fourth, there are small annoyances with the libmnl APIs which
are hard to fix in backward-compatible ways. See the last patch
for example.
All in all, libmnl is a great library, but with all the code
generation and structured parsing, ynl is better served by going
its own way.
v3:
patch 2:
- assume 4B alignment for {s,u}{16,32} getters
v2:
patch 2:
- NLA_ALIGN(sizeof(struct nlattr)) -> NLA_HDRLEN;
- ...put_strz() -> ...put_str()
- use ynl_attr_data() in ynl_attr_get_{str,s8,u8}()
- use signed helpers in signed auto-ints
- use ynl_attr_get_str() instead of ynl_attr_data() in ynl.c
patch 8:
- extend commit message
patch 10:
- fold NLMSG_NEXT(nlh, rem) into the for () statement
v1: https://lore.kernel.org/all/20240222235614.180876-1-kuba@kernel.org/
Jakub Kicinski (15):
tools: ynl: give up on libmnl for auto-ints
tools: ynl: create local attribute helpers
tools: ynl: create local for_each helpers
tools: ynl: create local nlmsg access helpers
tools: ynl: create local ARRAY_SIZE() helper
tools: ynl: make yarg the first member of struct ynl_dump_state
tools: ynl-gen: remove unused parse code
tools: ynl: wrap recv() + mnl_cb_run2() into a single helper
tools: ynl: use ynl_sock_read_msgs() for ACK handling
tools: ynl: stop using mnl_cb_run2()
tools: ynl: switch away from mnl_cb_t
tools: ynl: switch away from MNL_CB_*
tools: ynl: stop using mnl socket helpers
tools: ynl: remove the libmnl dependency
tools: ynl: use MSG_DONTWAIT for getting notifications
tools/net/ynl/lib/ynl-priv.h | 333 +++++++++++++++++++++++++++---
tools/net/ynl/lib/ynl.c | 365 +++++++++++++++++----------------
tools/net/ynl/lib/ynl.h | 3 +-
tools/net/ynl/samples/Makefile | 2 +-
tools/net/ynl/ynl-gen-c.py | 110 ++++------
5 files changed, 544 insertions(+), 269 deletions(-)
--
2.43.2
next reply other threads:[~2024-02-27 22:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 22:30 Jakub Kicinski [this message]
2024-02-27 22:30 ` [PATCH net-next v3 01/15] tools: ynl: give up on libmnl for auto-ints Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 02/15] tools: ynl: create local attribute helpers Jakub Kicinski
2024-02-28 8:21 ` Nicolas Dichtel
2024-02-27 22:30 ` [PATCH net-next v3 03/15] tools: ynl: create local for_each helpers Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 04/15] tools: ynl: create local nlmsg access helpers Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 05/15] tools: ynl: create local ARRAY_SIZE() helper Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 06/15] tools: ynl: make yarg the first member of struct ynl_dump_state Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 07/15] tools: ynl-gen: remove unused parse code Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 08/15] tools: ynl: wrap recv() + mnl_cb_run2() into a single helper Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 09/15] tools: ynl: use ynl_sock_read_msgs() for ACK handling Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 10/15] tools: ynl: stop using mnl_cb_run2() Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 11/15] tools: ynl: switch away from mnl_cb_t Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 12/15] tools: ynl: switch away from MNL_CB_* Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 13/15] tools: ynl: stop using mnl socket helpers Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 14/15] tools: ynl: remove the libmnl dependency Jakub Kicinski
2024-02-27 22:30 ` [PATCH net-next v3 15/15] tools: ynl: use MSG_DONTWAIT for getting notifications Jakub Kicinski
2024-02-28 23:50 ` [PATCH net-next v3 00/15] tools: ynl: stop using libmnl patchwork-bot+netdevbpf
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=20240227223032.1835527-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pabeni@redhat.com \
--cc=sdf@google.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).