On 11/29/2009 03:36 AM, David Miller wrote:

From: Jeff Kirsher<redacted>
Date: Wed, 25 Nov 2009 02:13:15 -0800

quoted

From: PJ Waskiewicz<redacted>

This adds Direct Attach SFP+ types to the connector ports
for the GSET mode.

Signed-off-by: Peter P Waskiewicz Jr<redacted>
Signed-off-by: Jeff Kirsher<redacted>

Jeff Garzik, ping?

These days, unless I have some massive objection, I merge stuff into 
ethtool when the kernel bits hit net-next.  ethtool should be current as 
of net-next 24 hrs ago.

I queued the ethtool patch in $subject, and was waiting on your kernel 
merge verdict.

Also, do you plan on doing any ethtool releases this century? :-)

I've been trying to think of what would be a good versioning scheme for 
ethtool.  Even though it is [essentially] a user-friendly kernel 
interface, its releases have never really been closely synchronized with 
the kernel releases.  And unlike a lot of other software, ethtool is so 
simple it does not really go through any release-candidate or beta period.

The current scheme just increments a release number: 5->6, 6->7, etc. 
But with so few kernel releases (and thus ethtool releases), I was 
leaning towards either yearly release naming ("ethtool-2009"), kernel 
release naming ("ethtool-2.6.33"), or the release scheme proposed for 
glibc:  snapshot directly from the git repository.

If people want one, I could do a release right now.  Or, we could move 
to an alternate scheme like git snapshots.  I think git snapshots are 
viable because ethtool has historically had next to zero bugs in the 
actual userland utility.  Fedora already imports git snapshots, for example.

Preferences?

	Jeff