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  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:	Thu, 05 Jul 2007 20:22:10 -0400
From:	Jeff Garzik <>
To:	"Kok, Auke" <>
CC:	Christoph Hellwig <>,
	Andrew Grover <>,
	Andrew Morton <>,
	Jason Lunz <>,
	Mark McLoughlin <>,,,
	"Ronciak, John" <>,
	"David S. Miller" <>,
	'Stephen Hemminger' <>,
	Andy Gospodarek <>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5

Kok, Auke wrote:
> 1a) We post an e1000e driver that implements support for all 8257x 
> (ich8/9, es2lan etc) devices.
> 1b) We post a patch that drops support for all of these devices in the 
> form of a pci-ID removal (no code removed) for e1000.
> 2) we post patches that remove code support for non-8254x devices at a 
> later stage.
> 3) we backport any and all cleanups and flags from e1000e to e1000 where 
> applicable.
> This plan leaves a significant gap that I'm worrying about: after step 
> (1) we basically have forced everyone to switch without providing a 
> fallback (allthough we have our out-of-tree driver, but no in-kernel 
> version in case issues exist).
> Comments?

I like the general gist of it.  My own suggestion would be

1) Create e1001.c, which is the SMALLEST POSSIBLE "it works" driver for 
ICH9.  No feature enablement (no TSO, no MQ, no IOAT, not even checksum 
offload), just a rock solid, no frills driver.  Think like e100.c :)

2) We review the hell out of e1001, and merge it.  This enables ICH9 
users, and ONLY ICH9 users, on e1001 in the upstream kernel, allowing us 
to blithely ignore driver->driver migration issues present with other chips.

At this point, e1001 is out in the field and in the upstream kernel in 
the absolute shortest amount of time.  Users of chips NOT found in 
current e1000 driver, and all future chips, can be enabled with little 
impediments, in parallel with the steps below.

(all the "3^y" steps can occur in parallel)

3^1) Add features to e1001, enabling new gizmos on new hardware.  This 
can proceed in parallel with any e1000 work.  This allows users to use 
git-bisect to find driver bugs -- or even hardware bugs, since you have 
a baseline working e1001 driver.

3^2) Add full ICH8 (8257x?) support to e1001.

4) Drop 8257x PCI IDs from e1000.  See who complains.  Lather, rinse, 

5) Figure out how the hell to clean up the current mess that is e1000, 
and how to make sure e1000 and e1001 stay clean, long term.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists