All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
To: Ben Greear <greearb@candelatech.com>
Cc: David Miller <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Eric Dumazet <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: Sat, 12 Dec 2009 23:09:24 -0800	[thread overview]
Message-ID: <1260688164.2142.84.camel@localhost> (raw)
In-Reply-To: <4B246B46.1010103@candelatech.com>

On Sat, 2009-12-12 at 20:19 -0800, Ben Greear wrote:
> On 12/12/2009 06:33 PM, Peter P Waskiewicz Jr wrote:
> > This is a follow-up to my first RFC, getting opinions where the best
> > place to put device-specific feature toggling would be.  The feedback I
> > received was to look at doing this in ethtool.  Below is a high-level
> > design of what I'd like to do, and wanted to vet this with the community
> > to see if this is aligned with what people would like to see.
> >
> > The general idea is to have a generic framework in ethtool to enumerate
> > device-specific commands.  A sample structure that would represent each
> > of these commands is:
> >
> > 	enum oem_cmds {
> > 		OEM_CMD_0 = 0,
> > 		OEM_CMD_1,
> > 		OEM_CMD_2,
> > 	...
> > 	etc.
> > 	...
> > 	};
> >
> > 	struct oem_feature_cmd {
> > 		/* Description of the feature */
> > 		char *description;
> >
> > 		/* Does the feature toggling requires a device reset */
> > 		u8 require_reset;
> >
> > 		/* The command-line name for the command */
> > 		char *oem_cmd_name;
> >
> > 		/* The command number assigned to this */
> > 		u32 oem_cmd;
> >
> > 		/* value for the command */
> > 		u32 oem_cmd_val;
> > 	};
> 
> I'd add a 32-bit field for flags, with require_reset being one of them.  I'd also
> align it so that it has no holes on 32/64 bit (put char*'s next to each other, maybe
> pad with another 32-bit 'spare' field.  Maybe even use uint64 for the pointers so
> that the struct size is same on 32-bit and 64-bit, to aid using 32-bit apps on
> 64-bit OS easily.
> 
> This way, as new uses are found for this, the structure remains binary compatible.
> 

Excellent points.  Thanks Ben!

-PJ


  reply	other threads:[~2009-12-13  7:09 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 [this message]
2009-12-14  4:19     ` David Miller
2009-12-14  6:12       ` Peter P Waskiewicz Jr

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=1260688164.2142.84.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.