netdev - Re: RFR: New e1000 driver (e1000new), 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: <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