netdev - Re: [RFC] iproute: Add support for extended ack to rtnl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 04 May 2017 11:36:36 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     netdev@...r.kernel.org
Subject: Re: [RFC] iproute: Add support for extended ack to rtnl_talk

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?

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