[PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Paul Gortmaker]

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

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
-- 
1.7.9.1

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Ondrej Zary]

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.

-- 
Ondrej Zary

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Paul Gortmaker]

[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

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Ondrej Zary]

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...

-- 
Ondrej Zary

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Paul Gortmaker]

[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

RE: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[David Laight]

> 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

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Alan Cox]

> 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

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Alan Cox]

> 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

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[David Miller]

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.

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Paul Gortmaker]

[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

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[David Miller]

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?

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Alan Cox]

> > 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.

Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.

[Emmanuel Fusté]

> 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
Oh sh**, even if I could understand the arguments for the MCA part I 
could not
  agree anymore on this.
I you go to this road, kill the m68k architecture and four or five more and
remove half or more of the drivers.
"meaningless printk" ? kill the printk, not the driver. "confuse users" ?
which users ? What you call a users in you comments are people which 
only use
mouse and graphic environments and for which printk are not for ...
Your whole patchset is build around the philosophy perfectly resumed by your
words:
"xxx is being removed, since the 20year old hardware simply isn't capable of
meeting today's software demands on CPU and memory resources."
Such subjective positions are not valid technicals arguments.
Following Linux since twenty years, I could say without making a big mistake
that this is not the Linux way of doing things. Linux would never be 
what it is
today in term of pure code architecture if the easy way of removing 
"disturbing"
and "obsolete in today standards" hardware support code was the way of doing
things.

But perhaps my old way of viewing things is no longer compatible with 
the new
  generations or in what Linux is going to be...

Emmanuel.

PS: My over reaction is PARTLY caused because of special historic symbol
3c501 hardware represent. It was one of the only (if not the only one) 
ethernet
card supported by the Apollo platform and DomainOS. A great and 
important part
of the computer / Unix history.