Because we decided a long time ago to do this driver split. And everyone at that
time agreed with that, and we set out to do this. And part of that plan was to
move (not copy) the device IDs over.
We accepted that that might break some kernel developers' systems in the process
and consulted several vendors and distros if they were OK with the change and they
all agreed with the plan.
I do not want people with PCI Express e1000 cards to use e1000 for any day longer
than is strictly needed, and I certainly do not want to prolong the period where
both drivers could work on their adapters. That will be a far bigger nightmare for
me than just a few kernel developers having a bad day.
I guarantee, I will get e-mails about 2.6.25+e1000(e) issues for far longer then
you guys :)
Users will outnumber us kernel developers in complaints if we keep the situation
unclear to them, and we already told them that they need to switch to e1000e for
their PCI Express devices. If we now do stuff like what you proposed in that
patch, we just prolong this confusion. That cannot be good for anyone. Imagine if
distro's start picking random device IDs or worse. Stuff like that is already
happening, and discussions like these just add to the confusion.
Again - If there is a way to auto-enable e1000e in the right way so that more
systems migrate better then I'm all for it (even if forcing E1000E=y). But it
seems that the various patches proposed don't cut it and frankly Kconfig is
completely inadequate as a hardware enabling script since it knows absolutely
nothing about the hardware in the first place. And it wasn't meant for that
either. `make oldconfig` is not the answer ;).
Again - this has happened before, I remember many of my boxes not booting because
SATA Kconfig options changed and all my boxes failed to move the proper Kconfig
symbols over when I ran `make oldconfig` myself. Somewhere around 2.6.20 or so.
Auke
--
