Re: [patch] e1000=y && e1000e=m regression fix

From: Ingo Molnar
Date: Thu Apr 10 2008 - 15:29:55 EST



* Kok, Auke <auke-jan.h.kok@xxxxxxxxx> wrote:

> >> config E1000E_ENABLED
> >> - def_bool E1000E != n
> >> + def_bool E1000E = y || ((E1000E != n) && (E1000 = E1000E))
>
> > Uh, that's /not/ what Ingo's patch does. His patch makes e1000
> > claim the e1000e IDs if e1000 is built-in and e1000e is a module.
>
> so that's definately _not_ what I would like to see at all. Matthew
> points out that this will just prolong users to use e1000 instead of
> e1000e (which is what they should be encouraged to switch to in those
> cases).
>
> so I'm dropping my ACK

why you want to cripple an existing, rather well working and popular
Linux driver is beyond me.

You have a wide array of measures if you want to migrate users to the
new and shiny e1000e driver: you can stop adding _new_ IDs to the old
driver, you can unsupport it, you can claim that it wont work in certain
situations, you can print out messages to the user in the dmesg (if
those messages are true), you can even remove IDs from it if the user
has the new driver enabled.

But what you cannot do is to intentionally cripple a popular driver.
It's plain stupid. It does not matter how many times you've announced
it, it's still madness. Unless your goal is to reduce the Linux userbase
as quickly as possible that is ... ;-)

And please understand: _you_ are the maintainer of this code so
_please_, if you wish to do so, solve the problem differently, but dont
just stand there _talking_. I gave you ample feedback about what the
problem is (which you initially denied to even exist) and i even wrote a
patch. You might never use e1000=y && e1000e=m or e1000=y && e1000e=n
but i do. Guys, the ball is in your court now.

> this patch doesn't solve anything [...]

huh? How can you claim that?? It definitely solved my problem. Did you
miss that aspect of my patch?

> [...] and we'll have the same issue back when 2.6.26 ships which will
> have no PCI Express device IDs in e1000.

... and not changing existing behavior for a perfectly well working
system is exactly what compatibility and smooth migration is about. New
drivers need several kernel releases to be fully known, to be fully
trusted and to be fully accepted and integrated - and not the least, to
be fully tested ...

These are all well-known principles. It's nothing new at all and there's
nothing special about it: dont break existing drivers and setups and
dont create silent side-effects between drivers.

Ingo
--
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/