[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47FBDBE9.9040700@garzik.org>
Date: Tue, 08 Apr 2008 16:56:09 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Ingo Molnar <mingo@...e.hu>
CC: Matthew Wilcox <matthew@....cx>,
"Kok, Auke" <auke-jan.h.kok@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
NetDev <netdev@...r.kernel.org>,
e1000-list <e1000-devel@...ts.sourceforge.net>,
linux-pci maillist <linux-pci@...ey.karlin.mff.cuni.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
"Ronciak, John" <john.ronciak@...el.com>,
"Allan, Bruce W" <bruce.w.allan@...el.com>,
Greg KH <greg@...ah.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [regression] e1000e broke e1000
Ingo Molnar wrote:
> No other
> PCI driver breaks like this.
That's because PCI ID transitions are extremely, extremely rare.
Not because this transition is particularly unusual.
> We've got three thousand Kconfig options -
> it is clearly not realistic for users to keep such details in mind to
> avoid pitfalls.
Agreed -- hence the multiple announcements, including in this thread, to
put said details into mind.
It's an unusual situation, thus it received announcements so that people
are aware of the transition taking place, and what to do about it.
> E1000=y && E1000E=m is uncommon but can easily happen.
> E1000=y && E1000E=m simply makes no sense in light of the PCI ID
> stealing that occurs if E1000E is enabled.
"makes no sense"... for your personal situation.
They are two independent drivers, and that's a valid mix of Kconfig
settings.
Someone could easily have an e1000 card in an e1000e machine, and come
up with that specific config mix.
It is not denial to say "people other than Ingo might validly choose
that config mix."
Overall, fundamentally, any transition of a user base from one driver to
another is going to be an ad-hoc process. That's the nature of the
problem -- each case is different.
So we avoid driver transitions if at all possible, as a general rule.
In this case, a rare exception to that rule, you have to hammer out a
user-education process as best you can.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists