netdev - Re: Splitting e1000 (Was: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Jul 2007 14:45:35 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Arjan van de Ven <arjan@...ux.intel.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Francois Romieu <romieu@...zoreil.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Grover <andy.grover@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	"Ronciak, John" <john.ronciak@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Andy Gospodarek <andy@...yhouse.net>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
 ?)

Jeff Garzik wrote:
> Kok, Auke wrote:
>> I would strongly vote for taking a stripped down e1000new then, mask out 
>> all the pci id's except ich9, remove all code for pre-pci-e silicon and 
>> remove the most annoying and needlessly complexing code like the 
>> semi-implemented multiqueue code that is in there.
> 
> I'm fine for that as a path forward.  I would think that would zap a lot 
> of the hooks.
> 
>> How we are going to improve the internal api then can subsequently be 
>> done upstream in steps: implement using phylib, reorganize the code. 
>> This would give the community a view on the progress.
>>
>> I fear that if I spend yet another 2 months offline working on making a 
>> minimal ich9 driver I will lose even more time and patience: Even though 
>> the current driver (with pre-pci-e stripped) might not be as nice as you 
>> want, at least we can work together on it. I would rather go with 
>> something I know that works, isn't too bad, and we have time and start 
>> reviewing upstream immediately.
> 
> "minimal ich9 driver" is more a metaphor, describing the seed from which 
> a clean driver would logically grow:  imagine a minimal ich9 driver, 
> then add TSO, add support for other PCI-e phys, etc.  Whether you do 
> this exercise in your head or on the computer makes no difference, as 
> long as you can see what the end result should look like.
> 
> Not asking for yet another driver...  Start with e1000new or whatever 
> base you like.  Post driver for review, get feedback, update, lather, 
> rinse, repeat.  If we're all responsive, it should not take long at all 
> to get something upstream-mergeable.  Solve the "big potato" issues 
> especially :)
> 
> 
>> Agreed. All current e1000 pci-e hardware is based on the same mac, so 
>> it's the logical split. The differences are PHYs and manageability, but 
> 
> OK

Sorry for not replying to this earlier (I was on vacation for 2 days). We had 
some internal discussions and all the noses appear to be facing in the proper 
direction. I'm very happy with this and it will be my highest priority to make 
this work. I will attempt to get a quick start on this and come with a start 
point driver as soon as I can. Thanks to everyones who commented!

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