From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
To: David Miller <davem@davemloft.net>
Cc: "greearb@candelatech.com" <greearb@candelatech.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
"mchan@broadcom.com" <mchan@broadcom.com>,
"bhutchings@solarflare.com" <bhutchings@solarflare.com>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
"shemminger@linux-foundation.org"
<shemminger@linux-foundation.org>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Subject: Re: RFC: ethtool: add device-specific feature support in a generic fashion
Date: Sun, 13 Dec 2009 22:12:00 -0800 [thread overview]
Message-ID: <1260771120.20884.17.camel@localhost> (raw)
In-Reply-To: <20091213.201957.232755179.davem@davemloft.net>
On Sun, 2009-12-13 at 20:19 -0800, David Miller wrote:
> From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Date: Sat, 12 Dec 2009 23:09:24 -0800
>
> > Excellent points. Thanks Ben!
>
> See ethtool_gstrings please.
>
Yes, I looked at this before, then started thinking about it harder than
I needed to.
> There is no reason to put a "char *" in any of your interfaces, just
> as we don't need to in the existing ethtool stats stuff.
>
Ah, right. Just a pointer to a chunk of data. I see now.
> And you can put the number of knobs available in struct
> ethtool_drvinfo right before n_priv_flags where we have a reserved
> area just for adding things like this.
>
> You are specifying way too much new stuff in your datastructures,
> unnecessary duplicating existing structures and facilities.
Yeah, I was making this too complicated. Glad I sent the RFC on the
design first before writing any code. :-)
> I pointed you at the ethtool private stats stuff because you
> can reuse %85 of it's implementation for your purposes :-)
Right! In this case, I just needed a firmer bonk on the head to look in
the right direction.
On the right track now Dave, thanks.
-PJ
prev parent reply other threads:[~2009-12-14 6:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-13 2:33 RFC: ethtool: add device-specific feature support in a generic fashion Peter P Waskiewicz Jr
2009-12-13 4:19 ` Ben Greear
2009-12-13 7:09 ` Peter P Waskiewicz Jr
2009-12-14 4:19 ` David Miller
2009-12-14 6:12 ` Peter P Waskiewicz Jr [this message]
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=1260771120.20884.17.camel@localhost \
--to=peter.p.waskiewicz.jr@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=greearb@candelatech.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=linville@tuxdriver.com \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.