Message-ID: <46912AEA.3030604@garzik.org>
Date:	Sun, 08 Jul 2007 14:20:26 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	"Kok, Auke" <auke-jan.h.kok@...el.com>, netdev@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jason Lunz <lunz@...lexsecurity.com>,
	Mark McLoughlin <markmc@...hat.com>,
	e1000-devel@...ts.sourceforge.net,
	"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9
 support from 7.5.5 ?

Arjan van de Ven wrote:
> Kok, Auke wrote:
>> Jeff Garzik wrote:
>>> Andrew Morton wrote:
>>>> On Fri, 29 Jun 2007 14:39:20 -0700
>>>> "Kok, Auke" <auke-jan.h.kok@...el.com> wrote:
>>>>
>>>>> That's why we want to introduce a second e1000 driver (named 
>>>>> differently, pick any name) that contains the new code base, 
>>>>> side-by-side into the kernel with the current e1000.
>>>> Sounds like a reasonable approach to me (it has plenty of 
>>>> precedent).  But
>>>> I forget what all the other issues were, so ignore me.
>>>
>>> Given past history with duplicate drivers and the problems that they 
>>> cause -- I know, I've caused some of those problems :( -- I strongly 
>>> recommend against when it can be avoided.
>>>
>>> Leaving e1000 with current hardware, and a new e1001 for newer 
>>> hardware should be easier to manage for all involved, without the 
>>> headaches that duplicate drivers cause.
>>>
> 
> Jeff,
> 
> ok first you hate the old e1000 and now you don't want to get rid of it ;)

No -- e1000 is big and bloated but also stable and working and a key 
popular NIC driver for a lot of people.

That means the transition has a wide impact, and thus should be 
considered a lot more carefully than (say) rewriting 8139cp.

I reject the notion that a "flag day" switchover for a huge mass of 
e1000 users is the correct path.  I do not think that best serves Linux 
users.

It is better to get a new driver out in the field and working for a 
small population, let time pass, then consider if we really want to 
transition the entire e1000 population to the new driver.  That leaves 
the mass of e1000 users with a working driver while the new driver 
proves itself.  Since a small population of users is required to use the 
new driver, by virtue of new/old PCI ID split, you are guaranteed a 
population of test users immediately for the new driver.

When the new driver proves itself stable, you will have plenty of 
knowledge from which to decide whether to transition 8257x users, all 
e1000 users, or whatever.


> I appreciate the pain a temporary dual driver situation gives; it comes 
> down to a few things that I can think of right now, if you see more 
> please add to the list.
> 
> 1) users who find a bug in the new one silently use the old one rather 
> than reporting the bug; and only scream when the old one eventually goes 
> away (see ALSA/OSS duplication)
> 
> 2) users who enable both in KConfig may get a "random" one
> 
> 3) distros really prefer only 1 driver per PCI ID for their 
> infrastructure tools
> 
> 4) there will be resistance against deleting the old one meaning it 
> might not happen

You are missing the largest source of pain and headache:  Users will use 
the default driver, which means no field testing at all until flag day, 
with obvious results.

Furthermore, Linux kernel history demonstrates that "temporary dual 
driver situations" are rarely temporary.  Thus, selling it as such in 
the face of all contrary experience is pure hyperbole.

	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

Powered by blists - more mailing lists