From: Adrian Bunk <hidden> Date: 2007-07-25 13:37:32
On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote:
...
Changes since 2.6.22-rc6-mm1:
...
git-e1000new.patch
...
git trees
...
Both e1000 drivers compiled into the kernel resulted in the following
compile error:
<-- snip -->
...
LD drivers/net/built-in.o
drivers/net/e1000/built-in.o: In function `e1000_read_mac_addr':
(.text+0xb9f2): multiple definition of `e1000_read_mac_addr'
drivers/net/e1000new/built-in.o:(.text+0x821a): first defined here
drivers/net/e1000/built-in.o: In function `e1000_phy_setup_autoneg':
(.text+0x8799): multiple definition of `e1000_phy_setup_autoneg'
drivers/net/e1000new/built-in.o:(.text+0xa9bd): first defined here
...
make[3]: *** [drivers/net/built-in.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <redacted>
---
BTW:
Unless I'm misunderstanding anything, the new driver should support a
superset of what the old driver supported.
Therefore, it would be good if the final merge into Linus' tree will
do an
rm -r drivers/net/e1000
mv drivers/net/e1000new drivers/net/e1000
From: Jeff Garzik <hidden> Date: 2007-07-25 13:49:20
Adrian Bunk wrote:
BTW:
Unless I'm misunderstanding anything, the new driver should support a
superset of what the old driver supported.
Therefore, it would be good if the final merge into Linus' tree will
do an
rm -r drivers/net/e1000
mv drivers/net/e1000new drivers/net/e1000
Based on the most recent discussion, e1000new (or whatever it will be
called) should support only the newer PCI-Express chips, while e1000
will retain support for the older chips.
Over the long term this will allow e1000new to grow without affecting
support for the older, stable chips.
So, e1000 is not going away.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
From: Adrian Bunk <hidden> Date: 2007-07-25 14:46:53
On Wed, Jul 25, 2007 at 09:48:55AM -0400, Jeff Garzik wrote:
Adrian Bunk wrote:
quoted
BTW:
Unless I'm misunderstanding anything, the new driver should support a
superset of what the old driver supported.
Therefore, it would be good if the final merge into Linus' tree will
do an
rm -r drivers/net/e1000
mv drivers/net/e1000new drivers/net/e1000
Based on the most recent discussion, e1000new (or whatever it will be
called) should support only the newer PCI-Express chips, while e1000 will
retain support for the older chips.
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
driver for new hardware).
Over the long term this will allow e1000new to grow without affecting
support for the older, stable chips.
So, e1000 is not going away.
No problem for me, but this obviously implies that global code in the
new driver has to be renamed.
And please ensure that they will always support distinct PCI IDs, or
there will be the following common pattern if both drivers support
a card:
- user tries driver A
- driver A doesn't work (although it should have worked)
- user tries driver B
- driver B works
- a later kernel removes support for this card from driver B
- user tries driver A
- driver A still doesn't work
- user writes bug report
Users should report bugs early instead of bouncing between different
drivers.
Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
From: Jeff Garzik <hidden> Date: 2007-07-25 15:05:20
Adrian Bunk wrote:
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
driver for new hardware).
Yeah, I think "e1000new" is a lame name.
e1000e is good, or even e1001e if we wanted even more symmetry :)
No problem for me, but this obviously implies that global code in the
new driver has to be renamed.
Yes. A global namespace is a global namespace.
And please ensure that they will always support distinct PCI IDs, or
there will be the following common pattern if both drivers support
a card:
IIRC I think Auke said there is some minor PCI ID overlap that must be
addressed in the transition. Disappointing and it raises transition
issues, but that's the way the split falls out naturally AFAICS.
Jeff
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
driver for new hardware).
Yeah, I think "e1000new" is a lame name.
Moreover, Andrew should probably just drop this driver from -mm for now.
e1000e is good, or even e1001e if we wanted even more symmetry :)
I'm working on "e1000e" right now...
quoted
No problem for me, but this obviously implies that global code in the
new driver has to be renamed.
Yes. A global namespace is a global namespace.
yes, these are some of the kinks I still need to address. Allthough minor, it's
going to take me some time to get it to the first step before I want to submit
it (patience :))
quoted
And please ensure that they will always support distinct PCI IDs, or
there will be the following common pattern if both drivers support
a card:
IIRC I think Auke said there is some minor PCI ID overlap that must be
addressed in the transition. Disappointing and it raises transition
issues, but that's the way the split falls out naturally AFAICS.
I'll submit it with only ich9 id's at first, but it will be able to drive (sysfs
bind) to some other devices too. This allows me to keep an eye out on the future
structure that I want to give it without removing too much code that I might
then later have to add back.
Auke
From: Jeff Garzik <hidden> Date: 2007-07-25 15:23:21
Kok, Auke wrote:
I'm working on "e1000e" right now...
Cool :)
I'll submit it with only ich9 id's at first, but it will be able to
drive (sysfs bind) to some other devices too. This allows me to keep an
eye out on the future structure that I want to give it without removing
too much code that I might then later have to add back.
Moreover, Andrew should probably just drop this driver from -mm for now.
gone..
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/