Merge branch 'tools-ynl-stop-using-libmnl'
Jakub Kicinski says: ==================== tools: ynl: stop using libmnl 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. v1: https://lore.kernel.org/all/20240222235614.180876-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20240227223032.1835527-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
Showing
This diff is collapsed.
This diff is collapsed.
Please register or sign in to comment