netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).