[ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Jeff Kirsher]

From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>

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

Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

 ethtool-copy.h |    3 +++
 ethtool.c      |    6 ++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3ca4e2c..7ea5a1b 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -402,6 +402,9 @@ struct ethtool_rxnfc {
 #define PORT_MII		0x02
 #define PORT_FIBRE		0x03
 #define PORT_BNC		0x04
+#define PORT_DA			0x05
+#define PORT_NONE		0xef
+#define PORT_OTHER		0xff
 
 /* Which transceiver to use. */
 #define XCVR_INTERNAL		0x00
diff --git a/ethtool.c b/ethtool.c
index 0110682..5b77614 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -942,6 +942,12 @@ static int dump_ecmd(struct ethtool_cmd *ep)
 	case PORT_FIBRE:
 		fprintf(stdout, "FIBRE\n");
 		break;
+	case PORT_DA:
+		fprintf(stdout, "Direct Attach Copper\n");
+		break;
+	case PORT_NONE:
+		fprintf(stdout, "None\n");
+		break;
 	default:
 		fprintf(stdout, "Unknown! (%i)\n", ep->port);
 		break;

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 25 Nov 2009 02:13:15 -0800

> From: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> 
> This adds Direct Attach SFP+ types to the connector ports
> for the GSET mode.
> 
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Jeff Garzik, ping?

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

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Jeff Garzik]

On 11/29/2009 03:36 AM, David Miller wrote:
> From: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> Date: Wed, 25 Nov 2009 02:13:15 -0800
>
>> From: PJ Waskiewicz<peter.p.waskiewicz.jr@intel.com>
>>
>> This adds Direct Attach SFP+ types to the connector ports
>> for the GSET mode.
>>
>> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>
> 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

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Jeff Garzik]

On 11/25/2009 05:13 AM, Jeff Kirsher wrote:
> From: PJ Waskiewicz<peter.p.waskiewicz.jr@intel.com>
>
> This adds Direct Attach SFP+ types to the connector ports
> for the GSET mode.
>
> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> ---
>
>   ethtool-copy.h |    3 +++
>   ethtool.c      |    6 ++++++
>   2 files changed, 9 insertions(+), 0 deletions(-)

applied

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Peter P Waskiewicz Jr]

On Sun, 2009-11-29 at 03:42 -0700, Jeff Garzik wrote:
> On 11/29/2009 03:36 AM, David Miller wrote:
> > From: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> > Date: Wed, 25 Nov 2009 02:13:15 -0800
> >
> >> From: PJ Waskiewicz<peter.p.waskiewicz.jr@intel.com>
> >>
> >> This adds Direct Attach SFP+ types to the connector ports
> >> for the GSET mode.
> >>
> >> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
> >> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> >
> > 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.
> 

I think we need a better versioning scheme no matter what method is
chosen.  If there are git snapshots, then part of the version in the
repo should include the git repo stamp, or a timestamp.  For example,
Fedora packages with the timestamp of the snapshot, but the actual
version of ethtool is "6git."  That isn't very helpful to me, since the
git snapshots with version 6git could be different.

That's my $0.02.

Cheers,
-PJ

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

On Sun, 2009-11-29 at 05:42 -0500, Jeff Garzik wrote:
[...]
> 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.

So does Debian.  But this is because we need to include the new
features, not because we like using snapshots.

> Preferences?

I think it should be based on kernel versions, so that it's clear
whether a given ethtool version supports the features introduced in a
given kernel version.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector ports

[Jeff Garzik]

On 11/30/2009 07:35 AM, Ben Hutchings wrote:
> On Sun, 2009-11-29 at 05:42 -0500, Jeff Garzik wrote:
>> 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.

> I think it should be based on kernel versions, so that it's clear
> whether a given ethtool version supports the features introduced in a
> given kernel version.

Sounds like kernel version it is.  Will debut ethtool-2.6.33 in a week 
or so, then.  I posted ethtool-2.6.33-pre1 just now (intentionally 
different from 2.6.33-rc1, to hint that ethtool release candidates need 
not march in lock step with kernel pre-releases).  Let some bug fixes 
trickle in, and then release ethtool-2.6.33.

	Jeff