the overdue eepro100 removal
Subsystems (3)
PATCH 1/1 the overdue eepro100 removal
This patch contains the overdue removal of the eepro100 driver.
---
Documentation/feature-removal-schedule.txt | 7 MAINTAINERS | 5 drivers/net/Kconfig | 14 drivers/net/Makefile | 1 drivers/net/eepro100.c | 2406 --------------------- 5 files changed, 2433 deletions(-)
MAINTAINERS renamed from MAINTAINERS.old +0 -5
@@ -1077,11 +1077,6 @@ W: bluesmoke.sourceforge.net S: Maintained -EEPRO100 NETWORK DRIVER -P: Andrey V. Savochkin -M: [email protected] -S: Maintained - EFS FILESYSTEM W: http://aeschi.ch.eu.org/efs/ S: Orphan
drivers/net/Kconfig renamed from drivers/net/Kconfig.old +0 -14
@@ -1471,20 +1471,6 @@ <file:Documentation/networking/net-modules.txt>. The module will be called dgrs. -config EEPRO100 - tristate "EtherExpressPro/100 support (eepro100, original Becker driver)" - depends on NET_PCI && PCI - select MII - help - If you have an Intel EtherExpress PRO/100 PCI network (Ethernet) - card, say Y and read the Ethernet-HOWTO, available from - <http://www.tldp.org/docs.html#howto>. - - To compile this driver as a module, choose M here and read - <file:Documentation/networking/net-modules.txt>. The module - will be called eepro100. - - config E100 tristate "Intel(R) PRO/100+ support" depends on NET_PCI && PCI
drivers/net/Makefile renamed from drivers/net/Makefile.old +0 -1
@@ -44,7 +44,6 @@ obj-$(CONFIG_TYPHOON) += typhoon.o obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o obj-$(CONFIG_PCNET32) += pcnet32.o -obj-$(CONFIG_EEPRO100) += eepro100.o obj-$(CONFIG_E100) += e100.o obj-$(CONFIG_TLAN) += tlan.o obj-$(CONFIG_EPIC100) += epic100.o
Documentation/feature-removal-schedule.txt renamed from Documentation/feature-removal-schedule.txt.old +0 -7
@@ -97,13 +97,6 @@ --------------------------- -What: eepro100 network driver -When: January 2007 -Why: replaced by the e100 driver -Who: Adrian Bunk <[email protected]> - ---------------------------- - What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports (temporary transition config option provided until then) The transition config option will also be removed at the same time.
drivers/net/eepro100.c deleted +0 -2406
2,406 lines not on this page · raw message
Quoted 1 line · Adrian Bunk
This patch contains the overdue removal of the eepro100 driver.
...
this needs to be resceduled for 2.6.24 (at least). We're hoping to merge the proposed changes (still being worked on) in .23. Milton Miller and David Acker are working on that.
Auke
Quoted 1 line · Auke
this needs to be resceduled for 2.6.24 (at least). We're hoping to merge the proposed changes (still being worked on) in .23. Milton Miller and David Acker are working on that.
Quite agreed.
Jeff
Quoted 4 lines · Adrian Bunk
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by Adrian Bunk <[email protected]>
The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip.
Signature · 3 lines
Bill Davidsen <[email protected]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
Quoted 7 lines · Bill Davidsen
Quoted 4 lines · Adrian Bunk
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by Adrian Bunk <[email protected]>The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip.
please see the thread "Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)" which is discussing a fix for this issue and currently being worked.
eepro100 will *still* be removed once e100 is fixed to support those devices.
Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards (patch coming this week!). That hopefully solves all e100 issues that are still open.
Auke
Please do not make unnecessary kernel changes which require changes in our systems.
Quoted 4 lines · Auke
Quoted 3 lines · Bill Davidsen
Quoted 2 lines · Adrian Bunk
This patch contains the overdue removal of the eepro100 driver.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Signed-off-by Adrian Bunk <[email protected]>The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip.
please see the thread "Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)" which is discussing a fix for this issue and currently being worked.
eepro100 will *still* be removed once e100 is fixed to support those devices.
Frankly I think there are more of us running old cards on PC hardware than people running ARM! And for a number of card for old buses like ISA, EISA, and VESA, the e100 has not worked. These are old PCs converted to routers and firewalls, and for security should not be left without upgrades.
Quoted 2 lines
Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards (patch coming this week!). That hopefully solves all e100 issues that are still open.
If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 2 lines · Bill Davidsen
Please do not make unnecessary kernel changes which require changes in our systems.
Welcome to the kernel 2.6 development model.
Quoted 20 lines
Quoted 19 lines · Auke
Quoted 5 lines · Bill Davidsen
Quoted 4 lines · Adrian Bunk
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by Adrian Bunk <[email protected]>Quoted 8 lines
The hardware supported by this driver is still in use, thanks. It's probably easier to leave the eepro100 driver in than find anyone who wants to investigate why the other driver (e100? from memory) doesn't work with some cards. As I recall this was suggested over a year ago and it was decided to leave it in, all of the reasons for doing so still seem valid. There really doesn't seem to be a benefit, it's not like people are working night and day to support new cards for this chip.
please see the thread "Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)" which is discussing a fix for this issue and currently being worked.
Quoted 7 lines
Quoted 3 lines
eepro100 will *still* be removed once e100 is fixed to support those devices.
Frankly I think there are more of us running old cards on PC hardware than people running ARM! And for a number of card for old buses like ISA, EISA, and VESA, the e100 has not worked. These are old PCs converted to routers and firewalls, and for security should not be left without upgrades.
WTF are you talking about?
Both drivers only support PCI cards.
Quoted 10 lines
Quoted 3 lines
Moreover, we now also have a fix for the e100 IPMI issues on some tyan boards (patch coming this week!). That hopefully solves all e100 issues that are still open.
If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work.
The goal is to get e100 better, and removing eepro100 helps with reaching this goal.
Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report?
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 11 lines · Adrian Bunk
Quoted 5 lines · Bill Davidsen
Please do not make unnecessary kernel changes which require changes in our systems.
If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work.
The goal is to get e100 better, and removing eepro100 helps with reaching this goal.
That's *your* goal, it should not be a shock that users have a goal of using their systems without having to reconfigure them every time there's a kernel upgrade containing a security fix.
Quoted 2 lines
Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report?
Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs.
If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 10 lines · Bill Davidsen
Quoted 8 lines · Adrian Bunk
Quoted 4 lines · Bill Davidsen
Please do not make unnecessary kernel changes which require changes in our systems.
If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work.
The goal is to get e100 better, and removing eepro100 helps with reaching this goal.
That's *your* goal, it should not be a shock that users have a goal of using their systems without having to reconfigure them every time there's a kernel upgrade containing a security fix.
unfortunately it is impossible for anyone to patch *every* old version of an OS there is. Not only do we not want to do this (too much work, little return), but most of the times it is exponentially more difficult to fix a security bug in an older OS version than a new one.
Quoted 5 lines
Quoted 2 lines
Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report?
Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs.
If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them.
as discussed before we really want to avoid having (1) an unmaintained bitrotting driver for X and (2) one that should work because people are being paid to take care of it.
The community has always encouraged us to work with us fixing the last issues in e100 to make it work for everyone. After all, we have all the documentation and facilities here to do almost all of the work.
I asked Adrian to postpone removing the eepro100 driver since we know that e100 is still not working on some platforms. However, if e100 is not working on your specific platform, then I would certainly like to know about your problem, and whether it still exists. This is orthogonal to your argument: Your complaint stands (and eepro100 will not be removed until we address the ARM platform issues), but I ask you kindly to work with us and test the current e100 driver and report any issues to us.
Cheers,
Auke
Quoted 3 lines · Auke
as discussed before we really want to avoid having (1) an unmaintained bitrotting driver for X and (2) one that should work because people are being paid to take care of it.
The community has always encouraged us to work with us fixing the last issues in e100 to make it work for everyone. After all, we have all the documentation and facilities here to do almost all of the work.
Agreed on all points.
Jeff
Quoted 15 lines · Bill Davidsen
Quoted 14 lines · Adrian Bunk
Quoted 11 lines · Bill Davidsen
Please do not make unnecessary kernel changes which require changes in our systems.
If you think the e100 driver fixes your problems use it and be happy. But since you don't have to test system behavior with the new driver, and you won't be called at night or on weekends if it doesn't work, do the rest of the world a favor and stop taking out things we know to work! Leaving in the eepro100 causes no work for you, and even if e100 works perfectly it needs to be validated in any sane network. it still makes work.
Quoted 7 lines
Quoted 4 lines
The goal is to get e100 better, and removing eepro100 helps with reaching this goal.
That's *your* goal, it should not be a shock that users have a goal of using their systems without having to reconfigure them every time there's a kernel upgrade containing a security fix.
For how many years do you know that there's a new and actively maintained e100 driver for your hardware?
And if you don't follow a stable line like the 2.6.16 kernel or a distribution kernel it's simply a part of the current development model that some kernel parts change. If changing one driver results in a big problem in your setup you should reconsider your setup. And every new kernel except for -stable kernels will anyway require a revalidation, so changing the network driver as part of this shouldn't be a big issue.
Quoted 11 lines
Quoted 4 lines
Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report?
Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs.
And exactly this is the reason why the eepro100 driver has to be removed, and that this will result in a better hardware support for everyone in the long term.
Quoted 6 lines
If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them.
I don't have a personal preference for the e100 driver (although it's working fine in my computer), but I have a preference for the benefits of having only one driver for a given hardware over having two drivers.
People like you use the eepro100 driver instead of reporting the bugs in the e100 driver you ran into.
This is exactly the problem with two different drivers having different hardware support, different features and different bugs we should avoid.
One driver supporting all hardware, having all features and all bug fixes is a huge benefit.
In your prevous email you were whining "And for a number of card for old buses like ISA, EISA, and VESA, the e100 has not worked." although eepro100 didn't support such cards.
Now you claim to speak for "the system administrators".
Please bring some technical points, preferably bug reports for problems with e100 that don't exist with eepro100.
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 6 lines · Adrian Bunk
On Mon, Jul 09, 2007 at 01:27:55PM -0400, Bill Davidsen wrote:
For how many years do you know that there's a new and actively maintained e100 driver for your hardware?
And if you don't follow a stable line like the 2.6.16 kernel or a distribution kernel it's simply a part of the current development model that some kernel parts change. If changing one driver results in a big problem in your setup you should reconsider your setup. And every new kernel except for -stable kernels will anyway require a revalidation, so changing the network driver as part of this shouldn't be a big issue.
Nothing is a "big issue" if you can force someone else to do the work. And if you have no impact from a production outage if some new driver works for hours and then does something unexpected.
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
Why didn't _you_ try the e100 driver when you validated your systems after you upgraded them to kernel 2.6, and if you did and it didn't work, where is your bug report?
Is that a joke, or subtle irony? Do you generally validate drivers you don't use just because your hardware might be able to support them? I don't validate various accelerated video drivers on systems running mostly text console, never check sound options on systems with an audio application, etc. After I tried the e100 driver on the first few systems and found issues (which may be resolved by now) I went back to eepro100 and used what worked. And used the driver for any new systems in other installs.
And exactly this is the reason why the eepro100 driver has to be removed, and that this will result in a better hardware support for everyone in the long term.
If this was a case of a kernel change requiring an effort to keep the driver I would not be suggesting someone take time to update the driver from threads to tasklets or fartlets or whatever the next ultimate irq handling happens to be. But when there's zero effort at the moment to retain the driver, I think it's change for the sake of change.
Signature · 3 lines
Bill Davidsen <[email protected]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
Quoted 8 lines · Bill Davidsen
If there were any benefit to removing a working driver I would at least be able to see it as a resources issue, but as far as I can see you just seem to have a personal preference for the e100 driver and want to force others to use it because you are so much better able to decide what users need than the system administrators. That's one of the reasons people choose open source, because they have a choice, and can use what's best for them.
And be thankful it is open source. If Microsoft drops a driver in Vista you don't have a choice. If Linux drops a driver you can go and patch it back in if you feel that passionate about it.
Unfortunately things change in life but at least you have the choice of being stuck with the old bit-rotting driver if you really want to.
Ian
Signature · 3 lines
Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group