On Thu, 4 May 2017 17:37:38 +0300 Leon Romanovsky <l...@kernel.org> wrote:
> On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann wrote: > > On 05/04/2017 01:56 AM, Stephen Hemminger wrote: > > > Add support for extended ack error reporting via libmnl. This > > > is a better alternative to use existing library and not copy/paste > > > code from the kernel. Also make arguments const where possible. > > > > > > Add a new function rtnl_talk_extack that takes a callback as an input > > > arg. If a netlink response contains extack attributes, the callback is > > > is invoked with the the err string, offset in the message and a pointer > > > to the message returned by the kernel. > > > > > > Adding a new function allows commands to be moved over to the > > > extended error reporting over time. > > > > > > For feedback, compile tested only. > > > > Just out of curiosity, what is the plan regarding converting iproute2 > > over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first > > user merged that requires libmnl, the only other user today in the > > tree is devlink, which even seems to define its own libmnl library > > helpers. What is the clear benefit/rationale of outsourcing this to > > libmnl? I always was the impression we should strive for as little > > dependencies as possible? > > And I would like to get direction for the RDMA tool [1] which I'm > working on it now. > > The overall decision was to use netlink and put it under iproute2 > umbrella. Currently, I have working RFC which is based on > legacy sysfs interface to ensure that we are converging on > user-experience even before moving to actual netlink defines. > > An I would like to continue to work on netlink interface, but which lib > interface > should I need to base rdmatool's netlink code? > > [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html > > > > > I don't really like that we make extended ack reporting now dependent > > on libmnl, which further diverts from iproute's native nl library vs > > requiring to install another nl library, making the current status > > quo even worse ... :/ > > > > Thanks, > > Daniel I would prefer new code use libmnl, but using libnetlink would also be ok. Any later conversion to libmnl would be mostly automated anyway. The real objection was copy/pasting in the kernel netlink parser. That was unnecessary bloat.
pgpA426sGjYe1.pgp
Description: OpenPGP digital signature
