On 08/11, Jakub Kicinski wrote:
Randomly adding Michal to CC since I just realized I forgot
to CC him on the series.
On Thu, 11 Aug 2022 08:01:52 -0700 Stephen Hemminger wrote:
> > On Wed, 10 Aug 2022 21:15:34 -0700 Stephen Hemminger wrote:
> > > Would rather this be part of iproute2 rather than requiring it
> > > to be maintained separately and part of the kernel tree.
> >
> > I don't understand what you're trying to say. What is "this",
> > what is "separate" from what?
>
> I am saying that ynl could live as a standalone project or as
> part of the iproute2 tools collection.
It's a bit of a strange beast, because the YNL C library ends up being
relatively small:
tools/net/ynl/lib/ynl.c | 528 +++++++++++++++++++++++++
tools/net/ynl/lib/ynl.h | 112 ++++++
The logic is mostly in the codegen:
gen.py | 1601 +++++++++++++++++++++++++
but that part we need for kernel C code as well.
The generated code is largish:
tools/net/ynl/generated/dpll-user.c | 371 ++++++++++++++++++
tools/net/ynl/generated/dpll-user.h | 204 ++++++++++
tools/net/ynl/generated/ethtool-user.c | 367 ++++++++++++++++++
tools/net/ynl/generated/ethtool-user.h | 190 +++++++++
tools/net/ynl/generated/fou-user.c | 322 ++++++++++++++++
tools/net/ynl/generated/fou-user.h | 287 ++++++++++++++
tools/net/ynl/generated/genetlink-user.c | 635
+++++++++++++++++++++++++++++++
tools/net/ynl/generated/genetlink-user.h | 201 ++++++++++
but we don't have to commit it, it can be created on the fly
(for instance when a selftest wants to make use of YNL).
Then again it would feel a lot cleaner for the user space library
to be a separate project. I've been putting off thinking about the
distribution until I'm done coding, TBH. Dunno.
my 2c:
Putting it into iproute2 will make it carry a 'networking' badge on it
meaning no other subsystem would look into it.
I'd rather make netlink more generic (s/netlink/kernelink/?) and remove
CONFIG_NET dependency to address https://lwn.net/Articles/897202/
