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]
Message-ID: <5785360B.50600@gmail.com>
Date:	Tue, 12 Jul 2016 11:25:15 -0700
From:	John Fastabend <john.fastabend@...il.com>
To:	"John W. Linville" <linville@...driver.com>,
	Jorge Alberto Garcia <jorge.garcia.gonzalez@...il.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, Ben Hutchings <ben@...adent.org.uk>,
	netdev <netdev@...r.kernel.org>
Subject: Re: ethtool TODO list - additional info

On 16-07-12 11:12 AM, John W. Linville wrote:
> On Tue, Jul 12, 2016 at 01:04:52PM -0500, Jorge Alberto Garcia wrote:
>> On Tue, Jul 12, 2016 at 12:55 PM, Jiri Pirko <jiri@...nulli.us> wrote:
>>> Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@...il.com wrote:
>>>> Hi !
>>>>
>>>> Some days ago, Jiri Pirko was talking about some next steps to
>>>> implement for ethtool.
>>>>
>>>> I haven't seen any follow up since ethtool's maintainer change. Can we have
>>>> additional details about these ?
>>>>
>>>> - libethtool - API
>>>> - generic netlink
>>>
>>> Yep, exactly, no reply. Apparently nobody really want to do any initiative
>>> here, and I'm lacking time to do it :(
>>>
>>
>> That's fine,  I already got  a git repo, I'm trying to understand what
>> 'use generic netlink' means.
>>
>> This is a piece of what grep got me on iproute git repo (I'm still
>> trying to understand)
>> grep -i netlink -r iproute2/
>> iproute2/bridge/mdb.c:#include "libnetlink.h"
>> iproute2/bridge/vlan.c:#include "libnetlink.h"
>> ...
>> ..
> 
> The general notion would be to replace the current ioctl-based
> ethtool API with one that is based on netlink, like many of the other
> networking APIs. I'm fine with the general idea of that, but so far
> I haven't heard a strong case for why it is necessary. It certainly
> doesn't seem urgent to me -- if someone disagrees, then please explain!
> 

And probably obvious but you can't remove the ioctl based ethtool
interface because we have a lot of software using it so you will have
to maintain both in parallel if there is a netlink equivalent.

Also most the stuff in ethtool tends to be things you set once at
init time or for debugging so the benefit of notifiers and such are
minimal.

Sure if I was doing it from scratch netlink would be better and there
are probably parts of it that are worth converting over where notifier
hooks and standardizing would be beneficial. I think Roopa for example
was coming up with some more general statistics mechanism.

My $.02 anyways.

JohnF

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ