netdev - Re: [PATCH 06/26] atl1: update initialization parameters

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] [day] [month] [year] [list]

Date:	Tue, 22 Jan 2008 21:30:49 -0500
From:	Chris Snook <csnook@...hat.com>
To:	Jay Cliburn <jacliburn@...lsouth.net>
CC:	Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org,
	atl1-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [PATCH 06/26] atl1: update initialization parameters

Jay Cliburn wrote:
> On Tue, 22 Jan 2008 04:56:11 -0500
> Jeff Garzik <jeff@...zik.org> wrote:
> 
>> jacliburn@...lsouth.net wrote:
>>> From: Jay Cliburn <jacliburn@...lsouth.net>
>>>
>>> Update initialization parameters to match the current vendor driver
>>> version 1.2.40.2.
> 
> [...]
> 
>> ACK without any better knowledge...  but is any addition insight 
>> available at all?
> 
> No, sorry Jeff.  I simply took the vendor's current driver and matched
> his initialization settings.  I can only assume he discovered these
> values through lab testing.
> 
> For this and the other "conform to vendor driver" patches in this set, I
> thought it important to have the in-tree driver match the vendor driver
> as closely as possible.  The primary motivations are (1) my belief that
> he's in a better position to test the NIC, and (2) to be able to go to
> him for assistance occasionally and not be rejected because of
> significant differences between his and our drivers.

I don't think we should be doing this without justification.  From all the atl1 
and atl2 code I've looked at, I've gotten the impression that their driver 
development processes are extremely ad-hoc.  There is code in the Atheros 
version of atl2 that cannot *possibly* apply to that hardware and was just 
copied and pasted from atl1, just as much of atl1 was copied and pasted from 
e1000.  The fact that various versions have different magic numbers may simply 
mean they copied and pasted from different irrelevant and incorrect sources.

Our contacts at Atheros seem to be very good electrical engineers, so when they 
tell us that a certain setting should be changed to match particular properties 
of the hardware, I trust them.  They are not, however, experienced and 
disciplined kernel developers, so absent such justification I think we should 
stick with what we have, which has been improved and reviewed by people who 
*are* experienced and disciplined kernel developers.

We have at least as much to teach Atheros about writing kernel code as they have 
to teach us about their hardware.

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