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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ