Re: [patch] e1000=y && e1000e=m regression fix (was: Re: [regression] e1000e broke e1000)

From: Frans Pop
Date: Wed Apr 09 2008 - 16:49:50 EST


Ingo Molnar wrote:
> Subject: e1000=y && e1000e=m regression fix
> From: Ingo Molnar <mingo@xxxxxxx>
> 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@xxxxxxx>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/