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.
next prev parent 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).