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

[Ingo Molnar]

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