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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B125014.9080507@garzik.org>
Date:	Sun, 29 Nov 2009 05:42:28 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	David Miller <davem@...emloft.net>
CC:	jeffrey.t.kirsher@...el.com, shemminger@...tta.com,
	netdev@...r.kernel.org, gospo@...hat.com,
	peter.p.waskiewicz.jr@...el.com
Subject: Re: [ethtool PATCH] ethtool: Add Direct Attach to the available connector
 ports

On 11/29/2009 03:36 AM, David Miller wrote:
> From: Jeff Kirsher<jeffrey.t.kirsher@...el.com>
> Date: Wed, 25 Nov 2009 02:13:15 -0800
>
>> From: PJ Waskiewicz<peter.p.waskiewicz.jr@...el.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@...el.com>
>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@...el.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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html