From: John Fastabend <john.fastabend@gmail•com>
To: "John W. Linville" <linville@tuxdriver•com>,
Jorge Alberto Garcia <jorge.garcia.gonzalez@gmail•com>
Cc: Jiri Pirko <jiri@resnulli•us>,
Ben Hutchings <ben@decadent•org.uk>,
netdev <netdev@vger•kernel.org>
Subject: Re: ethtool TODO list - additional info
Date: Tue, 12 Jul 2016 11:25:15 -0700 [thread overview]
Message-ID: <5785360B.50600@gmail.com> (raw)
In-Reply-To: <20160712181251.GA22464@tuxdriver.com>
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@resnulli•us> wrote:
>>> Tue, Jul 05, 2016 at 05:37:42PM CEST, jorge.garcia.gonzalez@gmail•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
next prev parent reply other threads:[~2016-07-12 18:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 15:37 ethtool TODO list - additional info Jorge Alberto Garcia
2016-07-12 17:55 ` Jiri Pirko
2016-07-12 18:04 ` Jorge Alberto Garcia
2016-07-12 18:12 ` John W. Linville
2016-07-12 18:25 ` John Fastabend [this message]
2016-07-12 18:34 ` David Miller
2016-07-12 19:18 ` John W. Linville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5785360B.50600@gmail.com \
--to=john.fastabend@gmail$(echo .)com \
--cc=ben@decadent$(echo .)org.uk \
--cc=jiri@resnulli$(echo .)us \
--cc=jorge.garcia.gonzalez@gmail$(echo .)com \
--cc=linville@tuxdriver$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox