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.
