From: Jeff Garzik <jgarzik@pobox.com>
To: Matthew Wilcox <willy@debian.org>
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] ethtool_ops rev 4
Date: Fri, 1 Aug 2003 12:25:36 -0400 [thread overview]
Message-ID: <20030801162536.GA18574@gtf.org> (raw)
In-Reply-To: <20030801154656.GW22222@parcelfarce.linux.theplanet.co.uk>
On Fri, Aug 01, 2003 at 04:46:56PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 01, 2003 at 11:40:21AM -0400, Jeff Garzik wrote:
> > Comments:
> >
> > * need SET_ETHTOOL_OPS macro or HAVE_ETHTOOL_OPS test macro or similar
>
> DaveM disagreed with that...
It's standard netdevice.h practice, and, he didn't disagree w/ my
rebuttal.
It is needed.
> > * I still do not see the need to change a simple storage of a constant
> > (into ethtool_gdrvinfo) into _four_ separate function call hooks (reg
> > dump len, eeprom dump len, nic-specific stats len, self-test len).
> > Internal kernel code that needs this information is always a slow path
> > anyway, so just call the ->get_drvinfo hook internally.
>
> slow path, sure, but increased stack usage. it's a tradeoff, and this way
> feels more clean to me.
Additing a function hook each time you want to retrieve a new integer
value? That's feels overly excessive to me.
> > * I prefer not to add '#include <linux/types.h>' to ethtool.h
>
> That means that any code which includes ethtool.h has to include types.h
> first (either implicitly or explicitly). The rule so far has been that
> header files should call out their dependencies explictly with an include
> of the appropriate file. So why *don't* you want it?
Because I copy it to userspace :)
Jeff
next prev parent reply other threads:[~2003-08-01 16:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-01 15:02 [PATCH] ethtool_ops rev 4 Matthew Wilcox
2003-08-01 15:40 ` Jeff Garzik
2003-08-01 15:46 ` Matthew Wilcox
2003-08-01 16:25 ` Jeff Garzik [this message]
2003-08-01 20:20 ` David S. Miller
2003-08-01 22:26 ` Jeff Garzik
2003-08-01 22:32 ` David S. Miller
2003-08-01 23:01 ` Jeff Garzik
2003-08-01 23:01 ` David S. Miller
2003-08-01 23:17 ` Jeff Garzik
2003-08-01 23:19 ` David S. Miller
2003-08-01 23:42 ` Jeff Garzik
2003-08-01 23:43 ` David S. Miller
2003-08-01 22:35 ` Jeff Garzik
2003-08-01 22:34 ` David S. Miller
2003-08-01 23:09 ` Jeff Garzik
2003-08-01 23:08 ` David S. Miller
2003-08-01 23:35 ` Jeff Garzik
2003-08-01 23:34 ` David S. Miller
2003-08-02 22:21 ` Matthew Wilcox
2003-08-02 22:34 ` Jeff Garzik
2003-08-03 0:27 ` Matthew Wilcox
2003-08-03 3:14 ` Jeff Garzik
2003-08-03 14:56 ` Matthew Wilcox
2003-08-03 17:09 ` Jeff Garzik
2003-08-05 14:32 ` Matthew Wilcox
2003-08-03 0:28 ` David S. Miller
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=20030801162536.GA18574@gtf.org \
--to=jgarzik@pobox.com \
--cc=netdev@oss.sgi.com \
--cc=willy@debian.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 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).