Cc: Jeff Garzik <jeff@...>, 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@...>
this is really not the solution imho, having e1000 builtin and e1000e as a module
is a perfectly viable choice. They are two separate drivers that are completely
independent.
I also think that the word "regression" is way out of proportion. I did not
complain myself when IDE/ATA->SATA driver merges broke all my systems and I was
pleasantly provided with the 'cannot find root vfs' message. (that's what I get
for running my own distro).
a plain user uses a distro which is aware of the issue and that will load e1000e
automatically, because it was tested by the distro.
that is just pushing the discussion to the wrong point. The decision has been made
a long time ago to split e1000 in two. now that we have two drivers, we have a
migration issue. you can't fix this migration issue by forcing a specific .config
endresult on the user.
I've seen suggestions that will alleviate the issue by adding a 'default E1000' to
the e1000e Kconfig section, and something like that makes sense to me and I still
would be happy to merge something like that.
I do not think that hiding the existence of e1000e for any user by always enabling
it will fix things at all however, and will just lead to a lot of other issues
later on.
Auke
--
