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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <469121C0.7040208@garzik.org>
Date:	Sun, 08 Jul 2007 13:41:20 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
CC:	Christoph Hellwig <hch@...radead.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,
	"Ronciak, John" <john.ronciak@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	'Stephen Hemminger' <shemminger@...ux-foundation.org>,
	Andy Gospodarek <andy@...yhouse.net>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
 ?)

Kok, Auke wrote:
> This is not acceptable and hardly fair to expect from us.
> 
> It also exposes users to endless delays and uncertainties as to a final 
> resolution. Not to mention that writing a driver from scratch for (just) 
> ich9 will take significant time, is silly since it's almost identical to 
> ich8 etc..
> 
> I don't think that anyone besides you and maybe one or two others are 
> interested in doing this rewrite from scratch. The rest of us would 
> rather see something much more similar to my original suggestion which 
> relieves the ich9-wishes for everyone and provides a good starting point 
> to go forward. Not to mention that a lot of that code is already there, 
> and at least cleaned up quite a bit already.

Let's review the history here:

* For -years-, Intel has been told to stream structural cleanups into 
e1000 (and ixgb), along with feature enablement.  None of these cleanups 
happened, and the result was today's bloated driver.

* Intel posts a new e1000 driver, which is just as complex, if not more so.

* Intel proposes a Linux user transition plan that amounts to an abrupt 
NIC driver switch for users on a widely used NIC platform.

* Intel immediately dismisses all alternate paths to e1000 change, and 
all major e1000new structural comments.

Thus in effect you are presenting the Linux community with one option 
(and only one) -- your e1000new as it exists today -- and demanding that 
that option be accepted.

More importantly, Intel is asking the Linux community to TRUST that 
Intel will be a good driver MAINTAINER, despite lack of encouraging 
evidence in that regard.

Will we continue to see INATTENTION to basic driver maintenance, with 
100% of resources being devoted new features, and 0% devoted to thinking 
about how best to create a maintainable driver for those features long term?

With e1000new, I see a driver that's internally modular, but no more 
maintainable.  I also see a driver that runs directly counter to what we 
normally do in this situation -- split it up into multiple drivers. 
When you find yourself reinventing a net driver API, that's a big hint 
your engineering is ass-backwards.

It's not acceptable and hardly fair to expect the Linux community to 
blindly swallow the single option you've presented us.

We're talking about one of the most widely used NIC drivers here. 
Proposing to flip a switch and dump all users on the new driver in a 
couple months time does not serve Linux users at all.  Introducing the 
new driver more slowly -- starting with ICH9 and any other PCI IDs not 
covered by e1000 -- gives the driver a chance to prove itself in the 
field and be introduced more slowly, while at the same time not 
dramatically disturbing the existing, working e1000 installed base.

Starting with a new driver for the new hardware is the right way to go. 
    Get that driver into the field, get it right, and THEN use that 
field experience to see what PCI IDs you want to transition from the 
older driver.  That path is minimal disruption for Linux users, and 
maximizes the changes of Linux users running a working, proven driver. 
And coincidentally, that path also gives you the freedom to do heavy 
development on the new driver, with minimal disruption of the majority 
of your userbase.

So in sum, (a) Intel does not appear to have thought through the driver 
transition, (b) Intel has not proven itself to be a maintainer, and (c) 
e1000new needs to be restructured.

	Jeff

-
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