[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4691458B.50403@linux.intel.com>
Date: Sun, 08 Jul 2007 13:14:03 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Jeff Garzik <jeff@...zik.org>
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 ?
> 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.
so the options we have is do it one pci id a time; and the suggestion
by others like Christoph has been to make the split at the PCI Express
switchover. Do you agree with that approach?
>
>> 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.
which is why the proposal that was below the text you quoted talks
about working with the distro kernel maintainers and get the new
driver default for their development releases etc etc.... that adds
a significant level of granularity. For example I'd not be surprised
if Fedora and Ubuntu test releases have orders of magnitude more users
than kernel.org "self compiloe" kernels.
> 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.
history also demonstrates it can be done (just look at Adrian Bunk and
the OSS drivers) as long as someone is determined to do it. It's not
easy, especially cases where the two drivers have different
maintainers who disagree, or represent different
interfaces/functionality; but it's very not impossible either.
-
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