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
| ||
|
Message-ID: <20170504204318.GB21130@orbyte.nwl.cc> Date: Thu, 4 May 2017 22:43:18 +0200 From: Phil Sutter <phil@....cc> To: Stephen Hemminger <stephen@...workplumber.org> Cc: David Miller <davem@...emloft.net>, dsahern@...il.com, daniel@...earbox.net, netdev@...r.kernel.org Subject: Re: [RFC] iproute: Add support for extended ack to rtnl_talk Hi, On Thu, May 04, 2017 at 09:43:56AM -0700, Stephen Hemminger wrote: > On Thu, 04 May 2017 10:41:03 -0400 (EDT) > David Miller <davem@...emloft.net> wrote: > > > From: David Ahern <dsahern@...il.com> > > Date: Thu, 4 May 2017 08:27:35 -0600 > > > > > On 5/4/17 3:36 AM, Daniel Borkmann wrote: > > >> 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? > > > > > > +1 > > > > Agreed, all else being equal iproute2 should be as self contained > > as possible since it is such a fundamental tool. > > Sorry, the old netlink code is more difficult to understand than libmnl. > Having dependency on a library is not a problem. There already is > an alternative implementation of ip commands in busybox for those > people trying to work in small environments. I second that. If you can't afford the extra ~24KB of libmnl on your system, you much rather can't afford the 20 times bigger ip binary, either. Regarding conversion to libmnl, which I investigated and started working on once: My gut feeling back then was that it's not quite worth the effor since iproute2 requires an intermediate layer of functions anyway. Another detail which I didn't like that much was libmnl's idiom of creating netlink messages on base of just a plain buffer and using mnl_nlmsg_put_header() et al. to populate it with data. I'm probably a bit biased since I did the conversion to c99-style initializers for the various struct req data types, but I didn't like the added run-time overhead to achieve just the same. So in summary, given that very little change happens to iproute2's internal libnetlink, I don't see much urge to make it use libmnl as backend. In my opinion it just adds another potential source of errors. Eventually this should be a maintainer level decision, though. :) Cheers, Phil
Powered by blists - more mailing lists