Cc: Kok, Auke <auke-jan.h.kok@...>, Matthew Wilcox <matthew@...>, Linux Kernel Mailing List <linux-kernel@...>, NetDev <netdev@...>, e1000-list <e1000-devel@...>, linux-pci maillist <linux-pci@...>, Andrew Morton <akpm@...>, David S. Miller <davem@...>, Linus Torvalds <torvalds@...>, Jesse Brandeburg <jesse.brandeburg@...>, Ronciak, John <john.ronciak@...>, Allan, Bruce W <bruce.w.allan@...>, Greg KH <greg@...>, Arjan van de Ven <arjan@...>, Rafael J. Wysocki <rjw@...>
Agreed, and agreed.
I haven't said NAK, but I think the suggested fix is a waste of time because
1) it breaks (by disallowing) a valid setup based on one report
2) it only happens to experienced kernel hackers with weird configs
3) the suggested fix binds together more tightly two drivers we are
trying to keep separate
4) it is a temporary situation that will go away in 2.6.26 anyway
So from my point of view, your request is to pick the breakage you don't
care about (#1, above) to fix the breakage you do care about.
It's a "pick your poison" choice, from my POV.
Given that POV, that's why I lean towards avoiding your Kconfig fix --
viewing this as a transition issue, and not something to be fixed by
limiting the choices of others.
But if everyone strongly agrees with you... go ahead and patch, I won't
NAK it.
I dislike the Kconfig system growing "temporary" hacks, which tend to
accumulate false dependencies over time. But I readily admit that's a
general principle and not a hard rule...
Jeff
--
