All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: 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 14:12:52 -0400	[thread overview]
Message-ID: <20160712181251.GA22464@tuxdriver.com> (raw)
In-Reply-To: <CAPfrtUcAuu5t7xQ-F4d-+AAbSByOzD7aBa_+UsE_xoXRdxEuoA@mail.gmail.com>

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!

John

> >
> >
> >>- sub commands syntax
> >>- TODO/bugzilla
> >>
> >>
> >>On Mon, Jul 4, 2016 at 9:24 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >>>>> I was thinking of adding a TODO file to the repository, but it's really
> >>>>> for the new maintainer to decide what to do.  So here's my list as a
> >>>>> suggestion:
> >>>>>
> >>>>> * Add regression test coverage for all sub-commands with complex logic
> >>>>>
> >>>>> * Internationalise output and error messages
> >>>>>
> >>>>> * Build a libethtool that handles all the API quirks and fallbacks for
> >>>>>   old kernel versions.  This might help people writing language
> >>>>>   bindings or other utilities that use the ethtool API.
> >>>>>
> >>>>> * Provide a 'cleaned up' ethtool (under some other name) that has:
> >>>>>   - More conventional sub-command syntax, i.e. no '-'/'--' prefix
> >>>>>   - More consistent output formatting
> >>>>
> >>>>That seems like a reasonable start for a TODO list. I'll bet there
> >>>>are a few people out there with other suggestions as well...?
> >>>
> >>> Before that, I would like to see ethtool migrate to use generic
> >>> netlink. Then, the new tool would be needed anyway, should exist within
> >>> iproute2 package and have similar command line syntax.
> >>>
> >>> I have some ideas about the gennetlink ethtool, have to find some time
> >>> to implement some initial part of it.
> 

-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2016-07-12 18:15 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 [this message]
2016-07-12 18:25       ` John Fastabend
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=20160712181251.GA22464@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=ben@decadent.org.uk \
    --cc=jiri@resnulli.us \
    --cc=jorge.garcia.gonzalez@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.