| Message ID | 1337362769-4676-1-git-send-email-paul.gortmaker@windriver.com |
|---|---|
| State | Deferred, archived |
| Delegated to: | David Miller |
| Headers | show |
On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote: > It was amusing that linux was able to make use of this 1980's > technology on machines long past its intended lifespan, but > it probably should go now -- it is causing issues in some > distros[1], and while that might be fixable, it is just not > worth it. > > [1] > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card- >not-detecting-934344/ That looks like a bug elsewhere and removing this driver will not fix it.
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 18/05/2012 (Fri 20:16) Ondrej Zary wrote: > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote: > > It was amusing that linux was able to make use of this 1980's > > technology on machines long past its intended lifespan, but > > it probably should go now -- it is causing issues in some > > distros[1], and while that might be fixable, it is just not > > worth it. > > > > [1] > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card- > >not-detecting-934344/ > > That looks like a bug elsewhere and removing this driver will not fix it. You miss the point. We've got someone with a modern i7 machine who is getting confused by seeing messages from some ancient 3c501 driver, but he doesn't have the context to know it is ancient and the message is a red herring. Will it fix a distro's broken init that tries to modprobe everything? No. Will it help by not muddying the waters with meaningless printk from 3c501 that confuse users? Yes. Thanks, Paul. > > -- > Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Paul Gortmaker <paul.gortmaker@windriver.com> Date: Fri, 18 May 2012 13:39:29 -0400 > It was amusing that linux was able to make use of this 1980's > technology on machines long past its intended lifespan, but > it probably should go now -- it is causing issues in some > distros[1], and while that might be fixable, it is just not > worth it. > > To set the context, the 3c501 was designed in the 1980's to be > used on 8088 PC-XT 8bit ISA machines. It was built using > discrete TTL components and truly looks like a relic of the past. > > But from a functional point of view, the real issue, as stated > in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can > only do one thing at a time -- while you are removing one packet > from the single-packet buffer it cannot receive another packet, > nor can it receive a packet while loading a transmit packet." > > You know things are not good when the Kconfig help text suggests > you make a cron job doing a ping every minute. > > Hardware that old and crippled is simply not going to be used by > anyone in a time where 10 year old 100Mbit PCI cards (that are > still functional) are largely give-away items. > > [1] http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-not-detecting-934344/ > > Cc: Alan Cox <alan@linux.intel.com> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Alan, any objections? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 19 May 2012 00:03:06 Paul Gortmaker wrote: > [Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 18/05/2012 (Fri 20:16) Ondrej Zary wrote: > > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote: > > > It was amusing that linux was able to make use of this 1980's > > > technology on machines long past its intended lifespan, but > > > it probably should go now -- it is causing issues in some > > > distros[1], and while that might be fixable, it is just not > > > worth it. > > > > > > [1] > > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-c > > >ard- not-detecting-934344/ > > > > That looks like a bug elsewhere and removing this driver will not fix it. > > You miss the point. We've got someone with a modern i7 machine who is > getting confused by seeing messages from some ancient 3c501 driver, but > he doesn't have the context to know it is ancient and the message is a > red herring. Will it fix a distro's broken init that tries to modprobe > everything? No. Will it help by not muddying the waters with > meaningless printk from 3c501 that confuse users? Yes. Are you going to remove all drivers that complain that the HW is not present because some broken script is trying to modprobe them all? Or only the first one? 3c501 is probably the first in alphabet. You remove that and the script will modprobe 3c503 then...
> You miss the point. We've got someone with a modern i7 machine who is > getting confused by seeing messages from some ancient 3c501 driver, > but he doesn't have the context to know it is ancient and the message > is a red herring. Will it fix a distro's broken init that tries to > modprobe everything? No. Will it help by not muddying the waters > with meaningless printk from 3c501 that confuse users? Yes. That seems a totally bogus reason for removing stuff. The kernel cannot manage every possible distribution and user screw up. They have more variety so they will always win the battle. Removing it because nobody is running one even in a museum might be a good reason, but then the driver still works fine. Also btw: the 3c501 isn't all TTL it's integrated. The 3c500 is all TTL and an amazing beast, its so big it won't fit a 16bit slot as it has to drop down after the connector to get all the chips on. (and yes I have a 3c500) However I don't think this is the right way to tackle the ethernet history situation. As with MCA we should pull *all* the real historical interest only bits in one go so it's immediately obvious where the break point is for all devices. That or we'll replace confused distros and uses with confused ancient machine owners, and the latter can be far more persistent and irritating ;) So should we dump ISA ? Alan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-not-detecting-934344/ > > > > Cc: Alan Cox <alan@linux.intel.com> > > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> > > Alan, any objections? Wrong reason to remove it, Perfectly reasonable it (and a pile of other ISA cards) ought to be shown the door. Check with the M68K people however. 3c501 won't matter to them but I'm not sure which of the other chips ended up on Amiga ISA bridges. I know NE2000 clones did. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alan Cox <alan@linux.intel.com> Date: Sat, 19 May 2012 13:30:38 +0100 > However I don't think this is the right way to tackle the ethernet > history situation. As with MCA we should pull *all* the real historical > interest only bits in one go so it's immediately obvious where the > break point is for all devices. I don't think ISA is ever going to be something we can completely eradicate. Bits of ISA'ness show up everywhere, from random PC southbridges to specialized busses shipped on 64-bit sparcs for 8-bit devices like floppies and serial ports. Therefore, unlike MCA, ISA is more of a kind of entity we'll have to eradicate piecemeal I think. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 13:30) Alan Cox wrote: > > You miss the point. We've got someone with a modern i7 machine who is > > getting confused by seeing messages from some ancient 3c501 driver, > > but he doesn't have the context to know it is ancient and the message > > is a red herring. Will it fix a distro's broken init that tries to > > modprobe everything? No. Will it help by not muddying the waters > > with meaningless printk from 3c501 that confuse users? Yes. > > That seems a totally bogus reason for removing stuff. The kernel cannot > manage every possible distribution and user screw up. They have more > variety so they will always win the battle. Unfortunate that Ondrej's comment led folks to focus on the above as if it was the primary reason. It was not. The sheer unusability of it as a real networking interface in today's world (that I listed) was the prime motivation for removal. It was barely useable in the 1995 world, and I can't imagine it has got better with age. Getting rid of possibly misleading messages like the printk in the i7 user's messages is just a fringe benefit. I can remove the text: "-- it is causing issues in some distros, and while that might be fixable, it is just not worth it." from the commit log[1] and I think the remaining description still stands on its own as being justified. > > Removing it because nobody is running one even in a museum might be a > good reason, but then the driver still works fine. I would suspect that is the case here though. Based on its limitations (one operation at a time please) - I can't imagine that anyone anywhere is running one (with the possible exception of one or maybe two informal museusms?). > > Also btw: the 3c501 isn't all TTL it's integrated. The 3c500 is all > TTL and an amazing beast, its so big it won't fit a 16bit slot as it > has to drop down after the connector to get all the chips on. It has been at least 15 years since I've seen one, and google couldn't find me a picture, so I was going on memory. 3c501 definitely still had a lot of discrete TTL chips for bus glue logic then, since I'm sure it was a busy looking board. > > (and yes I have a 3c500) I've never seen one of those, and I count myself lucky. :) > > However I don't think this is the right way to tackle the ethernet > history situation. As with MCA we should pull *all* the real > historical interest only bits in one go so it's immediately obvious > where the break point is for all devices. MCA was fortunately reasonably bounded in time -- i.e. it was confined largely to things unfit for any use today. EISA is somewhat the same. > > That or we'll replace confused distros and uses with confused ancient > machine owners, and the latter can be far more persistent and > irritating ;) > > So should we dump ISA ? Per Dave's comments, we'd have to restrict ISA in this context to mean ISA _drivers_ that support _only_ physical pluggable 8/16bit ISA bus cards. With possible inclusion of onboard chips that were only deployed on ancient motherboards well over 10 years ago -- e.g. onboard aha154x.c and etherexpress on lp486e board type stuff. Maybe that is what you implicitly meant anyways? But since ISA isn't as nicely bounded in time, I could easily envision someone with a 1GHz socket370 P3 and an ISA SMC-Ultra PnP connected to a cable modem in a closet somewhere. Sure, it is old, but it could be still doing the job of a _reliable_ workhorse. Replace SMC-ultra with 3c501 in the above, and the story falls apart and becomes laughable. This is with no disrespect for the 3c501 driver. It is purely from the hardware being of a different era. Both ISA, but one is 10-15 years newer than the other. If we throw away the ISA card drivers all at once, we'll end up keeping some things well past their best before date, and throwing out some stuff that might actually still be used by real people. This isn't at all fatal in itself, but something to consider when weighing against the value of a consistent "all this stuff goes away on day X" message. That, and the inevitable inability to get a consensus "yes" for a large removal of ISA _card_ drivers from a decision committee, made me think that piecemeal was better than no action. If folks think I'm wrong on the consensus part, I will gladly start forming an ISA _card_ driver list of candidates for some yet to be determined scheduled removal... Paul. [1] http://patchwork.ozlabs.org/patch/160144/ -- > Alan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 10:58) Ondrej Zary wrote: > On Saturday 19 May 2012 00:03:06 Paul Gortmaker wrote: > > [Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On > 18/05/2012 (Fri 20:16) Ondrej Zary wrote: > > > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote: > > > > It was amusing that linux was able to make use of this 1980's > > > > technology on machines long past its intended lifespan, but > > > > it probably should go now -- it is causing issues in some > > > > distros[1], and while that might be fixable, it is just not > > > > worth it. > > > > > > > > [1] > > > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-c > > > >ard- not-detecting-934344/ > > > > > > That looks like a bug elsewhere and removing this driver will not fix it. > > > > You miss the point. We've got someone with a modern i7 machine who is > > getting confused by seeing messages from some ancient 3c501 driver, but > > he doesn't have the context to know it is ancient and the message is a > > red herring. Will it fix a distro's broken init that tries to modprobe > > everything? No. Will it help by not muddying the waters with > > meaningless printk from 3c501 that confuse users? Yes. > > Are you going to remove all drivers that complain that the HW is not present > because some broken script is trying to modprobe them all? Or only the first > one? 3c501 is probably the first in alphabet. You remove that and the script > will modprobe 3c503 then... Per my other mail, I think to focus on this one user's issue misses the bigger picture entirely; the real issue was called out in the commit log: But from a functional point of view, the real issue, as stated in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can only do one thing at a time -- while you are removing one packet from the single-packet buffer it cannot receive another packet, nor can it receive a packet while loading a transmit packet." Regardless, to answer your questions: 1) No, obviously an rm-rf of all drivers that can't probe quietly was not going to happen; that was never implicilty or explicitly proposed. 2) From memory while working on the 3c503 driver 15 odd years ago, it could probe silently and semi reliably, which was impressive then, given it was pre ISA-PnP. It was worlds ahead of a 3c501 card. Paul. -- > > -- > Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Regardless, to answer your questions: > > 1) No, obviously an rm-rf of all drivers that can't probe quietly was > not going to happen; that was never implicilty or explicitly proposed. > > 2) From memory while working on the 3c503 driver 15 odd years ago, it > could probe silently and semi reliably, which was impressive > then, given it was pre ISA-PnP. It was worlds ahead of a 3c501 card. Probing for non-pnp ISA cards is definitely unreliable. Maybe some of these drivers should need to be explicitly enabled in the kernel config. That should let people with the cards use them, without the danger of unexpected error messages and possible system lockups! ISTR that the Olicom ISA-pnp token ring card would lock the bus solid if hit by the probe for the non-pnp variant! (or maybe it was the other way around). I hadn't realised how bad some of the 3cxxx cards were! I thought the 'parallel tasking' was all about starting to tx a frame while the host was still copting it to the tx fifo (and rx copies before end of frame), not that it couldn't receive while the host was reading out a packet. I was writing drivers for the amd lance at much the same time... (Mind you, the intel device of that era was somewhat difficult to use as well.) David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Probing for non-pnp ISA cards is definitely unreliable. > Maybe some of these drivers should need to be explicitly > enabled in the kernel config. The config is set by the distributions, not always cluefully. Non PnP ISA drivers won't autoload either as they have nothing to key off. > I hadn't realised how bad some of the 3cxxx cards were! The 3c500/01 were the first PC ethernet card ever so very very old. > I thought the 'parallel tasking' was all about starting > to tx a frame while the host was still copting it to the > tx fifo (and rx copies before end of frame), not that It was. Alan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt index b06c8c6..df1a5cf 100644 --- a/Documentation/networking/multicast.txt +++ b/Documentation/networking/multicast.txt @@ -15,7 +15,6 @@ IP-MRoute AllMulti hardware filters are of no help Board Multicast AllMulti Promisc Filter ------------------------------------------------------------------------ -3c501 YES YES YES Software 3c503 YES YES YES Hardware 3c505 YES NO YES Hardware 3c507 NO NO NO N/A diff --git a/drivers/net/Space.c b/drivers/net/Space.c index e3f0fac..d108fac 100644 --- a/drivers/net/Space.c +++ b/drivers/net/Space.c @@ -198,9 +198,6 @@ static struct devprobe2 isa_probes[] __initdata = { #if defined(CONFIG_APRICOT) || defined(CONFIG_MVME16x_NET) || defined(CONFIG_BVME6000_NET) /* Intel I82596 */ {i82596_probe, 0}, #endif -#ifdef CONFIG_EL1 /* 3c501 */ - {el1_probe, 0}, -#endif #ifdef CONFIG_EL16 /* 3c507 */ {el16_probe, 0}, #endif diff --git a/drivers/net/ethernet/3com/3c501.c b/drivers/net/ethernet/3com/3c501.c deleted file mode 100644 index bf73e1a..0000000 diff --git a/drivers/net/ethernet/3com/3c501.h b/drivers/net/ethernet/3com/3c501.h deleted file mode 100644 index 183fd55..0000000 diff --git a/drivers/net/ethernet/3com/Kconfig b/drivers/net/ethernet/3com/Kconfig index bad4fa6..854b8fe 100644 --- a/drivers/net/ethernet/3com/Kconfig +++ b/drivers/net/ethernet/3com/Kconfig @@ -18,20 +18,6 @@ config NET_VENDOR_3COM if NET_VENDOR_3COM -config EL1 - tristate "3c501 \"EtherLink\" support" - depends on ISA - ---help--- - If you have a network (Ethernet) card of this type, say Y and read - the Ethernet-HOWTO, available from - <http://www.tldp.org/docs.html#howto>. Also, consider buying a - new card, since the 3c501 is slow, broken, and obsolete: you will - have problems. Some people suggest to ping ("man ping") a nearby - machine every minute ("man cron") when using this card. - - To compile this driver as a module, choose M here. The module - will be called 3c501. - config EL3 tristate "3c509/3c529 (MCA)/3c579 \"EtherLink III\" support" depends on (ISA || EISA || MCA) diff --git a/drivers/net/ethernet/3com/Makefile b/drivers/net/ethernet/3com/Makefile index 1e5382a..74046af 100644 --- a/drivers/net/ethernet/3com/Makefile +++ b/drivers/net/ethernet/3com/Makefile @@ -2,7 +2,6 @@ # Makefile for the 3Com Ethernet device drivers # -obj-$(CONFIG_EL1) += 3c501.o obj-$(CONFIG_EL3) += 3c509.o obj-$(CONFIG_3C515) += 3c515.o obj-$(CONFIG_PCMCIA_3C589) += 3c589_cs.o
It was amusing that linux was able to make use of this 1980's technology on machines long past its intended lifespan, but it probably should go now -- it is causing issues in some distros[1], and while that might be fixable, it is just not worth it. To set the context, the 3c501 was designed in the 1980's to be used on 8088 PC-XT 8bit ISA machines. It was built using discrete TTL components and truly looks like a relic of the past. But from a functional point of view, the real issue, as stated in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can only do one thing at a time -- while you are removing one packet from the single-packet buffer it cannot receive another packet, nor can it receive a packet while loading a transmit packet." You know things are not good when the Kconfig help text suggests you make a cron job doing a ping every minute. Hardware that old and crippled is simply not going to be used by anyone in a time where 10 year old 100Mbit PCI cards (that are still functional) are largely give-away items. [1] http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-not-detecting-934344/ Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> --- Below is "format-patch -D" to omit full line-by-line deletions, for review only; full patch based on net-next of today is at: The following changes since commit 92113bfde2f0982daa5a372d67b62f3d55bbc88a: ipv6: bool conversions phase1 (2012-05-18 02:24:13 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git delete-3c501 for you to fetch changes up to 4a3da8d00afdf701a8ff6880180d234d8da8ab6f: drivers/net: delete old 8bit ISA 3c501 driver. (2012-05-18 13:10:01 -0400) ---------------------------------------------------------------- Paul Gortmaker (1): drivers/net: delete old 8bit ISA 3c501 driver. Documentation/networking/multicast.txt | 1 - drivers/net/Space.c | 3 - drivers/net/ethernet/3com/3c501.c | 896 -------------------------------- drivers/net/ethernet/3com/3c501.h | 91 ---- drivers/net/ethernet/3com/Kconfig | 14 - drivers/net/ethernet/3com/Makefile | 1 - 6 files changed, 0 insertions(+), 1006 deletions(-) delete mode 100644 drivers/net/ethernet/3com/3c501.c delete mode 100644 drivers/net/ethernet/3com/3c501.h