netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: Ben Greear <greearb@candelatech.com>
Cc: netdev@oss.sgi.com
Subject: Re: netdev_ops?
Date: Wed, 23 Jul 2003 00:34:39 -0700	[thread overview]
Message-ID: <20030723003439.684de751.davem@redhat.com> (raw)
In-Reply-To: <3F1E391B.80209@candelatech.com>

On Wed, 23 Jul 2003 00:28:27 -0700
Ben Greear <greearb@candelatech.com> wrote:

> In my case, if the net_device can return net_device_stats, then I want it to work.

This is not for you to decide.  That is the driver author's
choice.

Also, succeeding for _ANY_ ethtool command is going to give
a tool the impression that other basic ethtool commands should
work too.  Your patch makes many devices give very inconsistent
behavior.

> Yes, and since I am ignorant of that stuff, and have no hardware to
> test with, then I want to avoid it.  I can't imagine I'm the
> only one.  Overloading the ethtool ioctl is one way to avoid that pain..adding
> a new, similar ioctl would also work, but seems like duplicated
> effort to me.

The correct "fix" on the 2.4.x side is to add the appropriate ethtool
support to appropriate drivers that lack it and need this interface.
It is not your hack and it is not adding a new ioctl.

You still haven't said why parsing /proc/dev is so bad, and you
even admit that your tool has to fall back to this ANYWAYS.

> Since it seems very unlikly that this sort of patch will be accepted
> in the near future, how _DO_ you want to see new features added that
> require configuration (and reading) from user space?

I just showed you above how to fix this particular problem.  Add
ethtool support to the ethernet device in question, and submit this
change to jgarzik.  It isn't very hard work and things other than your
particular need stand to gain from it.

My final note:  You don't even have the problem you claim to have.
                Use your brain and 'grep' a little bit, ok? :-)

                egrep get_stats net/core/rtnetlink.c

                There it is, exactly what you need and supported on
                every single kernel out there.

  reply	other threads:[~2003-07-23  7:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-23  5:06 netdev_ops? Ben Greear
2003-07-23  5:07 ` netdev_ops? David S. Miller
2003-07-23  5:30   ` netdev_ops? Ben Greear
2003-07-23  6:02     ` netdev_ops? David S. Miller
2003-07-23  6:24       ` netdev_ops? Ben Greear
2003-07-23  6:27         ` netdev_ops? David S. Miller
2003-07-23  6:36           ` netdev_ops? Ben Greear
2003-07-23  7:01             ` netdev_ops? David S. Miller
2003-07-23  7:28               ` netdev_ops? Ben Greear
2003-07-23  7:34                 ` David S. Miller [this message]
2003-07-23  8:08                   ` netdev_ops? Ben Greear
2003-07-23  8:15                     ` netdev_ops? David S. Miller
2003-07-23 16:59   ` netdev_ops? Jeff Garzik

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=20030723003439.684de751.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=greearb@candelatech.com \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).