netdev - Re: e1000: backport ich9 support from 7.5.5 ?

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:	Sat, 30 Jun 2007 15:31:10 +0100
From:	James Chapman <jchapman@...alix.com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
CC:	Jeff Garzik <jeff@...zik.org>,
	Andrew Grover <andy.grover@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jason Lunz <lunz@...lexsecurity.com>,
	Mark McLoughlin <markmc@...hat.com>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: e1000: backport ich9 support from 7.5.5 ?

Kok, Auke wrote:
> Jeff Garzik wrote:
>> Can knowledgeable people characterize the PCIe adapters somehow?  Is 
>> that "ICH8-era and later", or does it go back further than that?
> 
> ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the 
> 82571 design with different PHY's, and added features for the newer 
> demands. A driver split here would be possible but not justified IMHO.
>
 > if you want a quick view of features by chipset type, open the patch
 > and search forward to /e1000_setup_flags/.

I briefly looked over your new driver. I think it might benefit by 
moving common parts into one or more libraries (or modules) and have 
separate chip-specific drivers for 82540, 82541, 82542, 82543, 82571 
etc. Put all the chip-specific bits in a chip-specific driver and have 
each driver call into the common (shared) code. The device 
probe/init/remove would be done by the chip-specific code, not the 
common code like it is now. When built as a module, the chip-specific 
parts and the common parts could be built as separate modules; modprobe 
would load the common parts automatically. Most of the code would be in 
the common part since these chips are very similar.

Doing the above would lead naturally to a series of patches which will 
make it easier to review. When Intel release a new device variant in the 
future, it might be supported by a new, small driver rather than needing 
modifications to one big monolith. Also, the kernel would be loaded with 
only the code it needed to support the specific device(s) present.

BTW, since you're doing a major update, would it be a good time to 
switch to phylib to manage your PHYs?

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

-
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