netdev - Re: [RFC] introducing the Atheros L2 Fast Ethernet driver

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]

Message-ID: <475607A9.90000@redhat.com>
Date:	Tue, 04 Dec 2007 21:06:33 -0500
From:	Chris Snook <csnook@...hat.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	netdev@...r.kernel.org, synrg@...ian.org
Subject: Re: [RFC] introducing the Atheros L2 Fast Ethernet driver

Jeff Garzik wrote:
> Chris Snook wrote:
>> Hey folks --
>>
>>     I've begun cleaning up the atl2 vendor driver for merging.  It's 
>> very similar to the atl1 driver, and needs a lot of the same work, 
>> though I have already fixed the 64-bit DMA data corrupter that atl1 
>> users remember so fondly.  Right now this is very raw, and there is a 
>> large amount of cosmetic work to do to make it more maintainable, but 
>> it should generally work, at least as well as the vendor driver does.
>>
>>     While this is in pre-submission cleanup mode, the latest 
>> standalone source tarball and patch (currently against 2.6.23) will be 
>> available here:
>>
>> http://people.redhat.com/csnook/atl2/
>>
>>     If you have atl2 hardware, please give this a spin.  I plan to 
>> submit the driver for merging some time in the next month or so.  
>> Questions, comments, patches welcome.
> 
> Why not update atl1 for this new hardware?  Why is a new driver needed?
> 
>     Jeff

They have some common hardware at the PCIe level, but at the ethernet level it's 
totally different (simple, low-power 100 Mb vs. Gb with all the bells and 
whistles).  We'd end up special-casing all over the place, because they have 
rather different capabilities, like, say, if we tried to merge ixgb and e1000 
(which have a lot of code in common).  It could be done, but I don't think it 
would be beneficial.  If Atheros decides to maintain the in-tree drivers 
directly, and wants to take it in that direction, I won't object, but from where 
I sit, on the other side of the planet from the guys with the chips hooked up to 
the hardware analyzers, separate drivers seems less painful.

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