From: Ben Greear <greearb@candelatech.com>
To: "David S. Miller" <davem@redhat.com>
Cc: netdev@oss.sgi.com
Subject: Re: netdev_ops?
Date: Wed, 23 Jul 2003 00:28:27 -0700 [thread overview]
Message-ID: <3F1E391B.80209@candelatech.com> (raw)
In-Reply-To: <20030723000130.3a6a917e.davem@redhat.com>
David S. Miller wrote:
> On Tue, 22 Jul 2003 23:36:25 -0700
> Ben Greear <greearb@candelatech.com> wrote:
>
>
>>I am not writing drivers, I'm trying to write code that works with
>>everything that looks remotely like an ethernet device.
>
>
> Making ethtool interfaces available on every net device is not right,
> what about the ISDN folks? What if they specifically want ethtool
> ioctls to fail for their devices? How can one accomplish that after
> your changes?
>
> Answer: You can't.
In my case, if the net_device can return net_device_stats, then I want it to work.
If it can't, -ENOTSUPP is returned. I cannot fathom a reason for this
in itself to harm anyone. As you noticed below, existing code would never
try this ioctl, and new code can likewise ignore it if it cannot handle
the consequences.
> Whatever tools you write which depend upon this will not work
> on any existing 2.4.x kernel, therefore making their utility
> basically NIL.
That can be said for every new feature or ioctl. Of course
it won't work with older stuff...but it will work with newer
stuff, and I'm smart enough to be able to fall back to the
less efficient parsing of /proc/net/dev if the ioctls are
not supported. Anyone else that cares can write programs just
as clever.
> What is this "other platform" issue?
>
> If you add anything new, along the lines of SIOCDEVETHTOOl, it's
> going to have to go through an entire full review process and in
> that review process any necessary 32-bit ioctl translation code
> would get added.
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.
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? IOCTLs are easy to add on x86
at least, but maybe you'd prefer some text based proc interface instead?
Ben
--
Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
next prev parent reply other threads:[~2003-07-23 7:28 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 ` Ben Greear [this message]
2003-07-23 7:34 ` netdev_ops? David S. Miller
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=3F1E391B.80209@candelatech.com \
--to=greearb@candelatech.com \
--cc=davem@redhat.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).