Ingo Molnar wrote:
quoted text
> Subject: e1000=y && e1000e=m regression fix
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed Apr 09 21:09:35 CEST 2008
> 
> fix a regression from v2.6.24: do not transfer the e1000e PCI IDs from
> e1000 to e1000e if e1000 is built-in and e1000e is a module.
> 
> Built-in drivers take precedence over modules in many ways - and in this
> case it's clear that the user intended the e1000 driver to be the
> primary one. "Silently change behavior and break existing configs" is
> never a good migration strategy. Most users will use distro kernels that
> are not affected by this problem at all - nor are they affected by this
> patch - but this problem can hit users and developers who build their
> kernels themselves and migrate from v2.6.24 to v2.6.25.
> 
> this fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10427
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>

Speaking as someone who's mostly (guestimated at 97% ;-) a user, I'd be in 
favor of a patch like this.

The scenario I have in mind that would lead to exactly the situation Ingo is 
trying to solve is this:
Fairly experienced user wants a kernel which supports his hardware without 
having to load modules, but wants other modules available "just in case".
So he takes his distro kernel and selectively changes some modules to 
built-ins, including e1000.
Next he upgrades to 2.6.25 and finds his NIC no longer works. Files bug 
reports all over the place and loads of people waste valuable time trying 
to help him. I doubt any of the people trying to help (who are trying to do 
so without access to the hardware) will soon think of this scenario. It's 
much more likely they'll get stuck on "but e1000e is available as a module, 
so it should get loaded, right".
Maybe, just very maybe, someone, in an act of desperation will say "ok, try 
compiling in the module, see if that works".

Or maybe they will stumble on this thread at some point. Anyway, I 
completely agree with Ingo that it would be really nice if all the wasted 
time and frustration could just be avoided.

Cheers,
FJP
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/