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]

Date:	Sun, 29 Nov 2009 10:35:51 -0800
From:	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	David Miller <davem@...emloft.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"shemminger@...tta.com" <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>
Subject: Re: [ethtool PATCH] ethtool: Add Direct Attach to the available
 connector ports

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@...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.
> 

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

--
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