remove the broken SCSI_SEAGATE driver

PATCH In review Adrian Bunk 5 participants 12 messages Dec 12, 2006 – Dec 18, 2006 SCSI

Share & tools

Adrian Bunk

author

2006-12-12 16:22 UTC #0 lore raw

PATCH 1/1 remove the broken SCSI_SEAGATE driver

The SCSI_SEAGATE driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.

Drivers that had been marked as BROKEN for such a long time seem to be unlikely to be revived in the forseeable future.

But if anyone wants to ever revive this driver, the code is still present in the older kernel releases.

Signed-off-by Adrian Bunk <[email protected]>

---

This patch was already sent on:
- 25 Nov 2006
- 20 Nov 2006

 drivers/scsi/Kconfig   |   13 
 drivers/scsi/Makefile  |    3 
 drivers/scsi/seagate.c | 1666 -----------------------------------------
 3 files changed, 1682 deletions(-)

drivers/scsi/Kconfig renamed from drivers/scsi/Kconfig.old +0 ~~-13~~

@@ -1277,19 +1277,6 @@
           This lpfc driver supports the Emulex LightPulse
           Family of Fibre Channel PCI host adapters.
 
-config SCSI_SEAGATE
-	tristate "Seagate ST-02 and Future Domain TMC-8xx SCSI support"
-	depends on X86 && ISA && SCSI && BROKEN
-	---help---
-	  These are 8-bit SCSI controllers; the ST-01 is also supported by
-	  this driver.  It is explained in section 3.9 of the SCSI-HOWTO,
-	  available from <http://www.tldp.org/docs.html#howto>.  If it
-	  doesn't work out of the box, you may have to change some macros at
-	  compiletime, which are described in <file:drivers/scsi/seagate.c>.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called seagate.
-
 # definitely looks not 64bit safe:
 config SCSI_SIM710
 	tristate "Simple 53c710 SCSI support (Compaq, NCR machines)"

drivers/scsi/Makefile renamed from drivers/scsi/Makefile.old +0 -3

@@ -16,7 +16,6 @@
 
 CFLAGS_aha152x.o =   -DAHA152X_STAT -DAUTOCONF
 CFLAGS_gdth.o    = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS
-CFLAGS_seagate.o =   -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
 
 subdir-$(CONFIG_PCMCIA)		+= pcmcia

@@ -88,8 +87,6 @@
 obj-$(CONFIG_SCSI_QLA_ISCSI)	+= qla4xxx/
 obj-$(CONFIG_SCSI_LPFC)		+= lpfc/
 obj-$(CONFIG_SCSI_PAS16)	+= pas16.o
-obj-$(CONFIG_SCSI_SEAGATE)	+= seagate.o
-obj-$(CONFIG_SCSI_FD_8xx)	+= seagate.o
 obj-$(CONFIG_SCSI_T128)		+= t128.o
 obj-$(CONFIG_SCSI_DMX3191D)	+= dmx3191d.o
 obj-$(CONFIG_SCSI_DTC3280)	+= dtc.o

drivers/scsi/seagate.c deleted +0 ~~-1666~~

1,666 lines not on this page · raw message

James Bottomley

2006-12-12 23:37 UTC #1 lore raw

Quoted 9 lines · Adrian Bunk

The SCSI_SEAGATE driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still present in the older kernel releases.

Would you care to explain the rationale for this, please. If the driver had been riddled with errors and compilation problems, I might have acquiesced, but now I come to look it over, it seems structurally reasonably OK (we certainly have non-BROKEN worse ones) plus it compiles fine. So I'm wondering why it's marked broken in the first place.

Since it was your original patch:

Author: Adrian Bunk <[email protected]>
Date:   Mon Sep 1 19:22:52 2003 -0700

[PATCH] Mark more drivers BROKEN{,ON_SMP}

- let more drivers that don't compile depend on BROKEN
- MTD_BLKMTD is fixed, remove the dependency on BROKEN
- let all drivers that don't compile on SMP (due to cli/sti usage) depend on a BROKEN_ON_SMP that is only defined if !SMP || BROKEN
- #include interrupt.h for dummy cli/sti/... in two files to fix the UP compilation of these files

I marked only drivers that are broken for a long time and where I don't know about existing fixes with BROKEN or BROKEN_ON_SMP.

I'd like to know why it was marked BROKEN in the first place.

Thanks,

James

Adrian Bunk

author

2006-12-13 00:08 UTC #2 lore raw

Quoted 31 lines · James Bottomley

Quoted 9 lines · Adrian Bunk
The SCSI_SEAGATE driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still present in the older kernel releases.
Would you care to explain the rationale for this, please. If the driver had been riddled with errors and compilation problems, I might have acquiesced, but now I come to look it over, it seems structurally reasonably OK (we certainly have non-BROKEN worse ones) plus it compiles fine. So I'm wondering why it's marked broken in the first place.
Since it was your original patch:
Author: Adrian Bunk <[email protected]>
Date:   Mon Sep 1 19:22:52 2003 -0700
[PATCH] Mark more drivers BROKEN{,ON_SMP}
- let more drivers that don't compile depend on BROKEN
- MTD_BLKMTD is fixed, remove the dependency on BROKEN
- let all drivers that don't compile on SMP (due to cli/sti usage) depend on a BROKEN_ON_SMP that is only defined if !SMP || BROKEN
- #include interrupt.h for dummy cli/sti/... in two files to fix the UP compilation of these files

Quoted 4 lines

I marked only drivers that are broken for a long time and where I don't know about existing fixes with BROKEN or BROKEN_ON_SMP.
I'd like to know why it was marked BROKEN in the first place.

There must have been a compile error that has since been fixed, but I don't remember the details of this specific driver and I don't have such old compile logs anymore.

Quoted 3 lines

Thanks,
James

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 Seed

Krzysztof Halasa

2006-12-15 14:00 UTC #3 lore raw

Quoted 3 lines · Adrian Bunk

There must have been a compile error that has since been fixed, but I don't remember the details of this specific driver and I don't have such old compile logs anymore.

I wonder if we could gather some usage statistics, especially WRT really old hardware.

Perhaps we could invent some MODULE_WARN_OBSOLETE thing which would warn users about their drivers being removed in +6m (or maybe +12m), unless they let us know at http://qwe or mailto:ads?

I find it really hard to believe there are still users of things like CDU-31A CDs, XT MFM disk controllers, or NCR5380 SCSI host adapters (especially the real ones, not DOMEX etc. clones bundled with scanner just ~ 10 years ago).

Signature · 1 line

Krzysztof Halasa

Oliver Neukum

2006-12-15 14:10 UTC #4 lore raw

Am Freitag, 15. Dezember 2006 14:34 schrieb Krzysztof Halasa:

Quoted 4 lines

I find it really hard to believe there are still users of things like CDU-31A CDs, XT MFM disk controllers, or NCR5380 SCSI host adapters (especially the real ones, not DOMEX etc. clones bundled with scanner just ~ 10 years ago).

If they do, they probably rarely update their kernel. But not never.

Regards
Oliver

James Bottomley

2006-12-15 16:02 UTC #5 lore raw

In reply to Krzysztof Halasa

Quoted 9 lines · Krzysztof Halasa

Quoted 3 lines · Adrian Bunk
There must have been a compile error that has since been fixed, but I don't remember the details of this specific driver and I don't have such old compile logs anymore.
I wonder if we could gather some usage statistics, especially WRT really old hardware.

Quoted 8 lines

Perhaps we could invent some MODULE_WARN_OBSOLETE thing which would warn users about their drivers being removed in +6m (or maybe +12m), unless they let us know at http://qwe or mailto:ads?
I find it really hard to believe there are still users of things like CDU-31A CDs, XT MFM disk controllers, or NCR5380 SCSI host adapters (especially the real ones, not DOMEX etc. clones bundled with scanner just ~ 10 years ago).

I really don't see a need to declare drivers obsolete unless they bitrot to the point they're demonstrably useless and no-one wants to step up to fix them, which is what the BROKEN flag is for.

James

Krzysztof Halasa

2006-12-17 20:03 UTC #6 lore raw

Quoted 3 lines · James Bottomley

I really don't see a need to declare drivers obsolete unless they bitrot to the point they're demonstrably useless and no-one wants to step up to fix them, which is what the BROKEN flag is for.

How do you know if the driver is broken? Especially if it still compiles?

Some of these things are 20 years old.

Signature · 1 line

Krzysztof Halasa

James Bottomley

2006-12-17 20:24 UTC #7 lore raw

Quoted 10 lines · Krzysztof Halasa

Quoted 3 lines · James Bottomley
I really don't see a need to declare drivers obsolete unless they bitrot to the point they're demonstrably useless and no-one wants to step up to fix them, which is what the BROKEN flag is for.
How do you know if the driver is broken? Especially if it still compiles?
Some of these things are 20 years old.

One of the touted benefits of Linux is that we run on old hardware. Unless the driver is demonstrably wrong (and they do become so as the APIs evolve) or it fails to compile because of bitrotting, there's no real urgency to remove it, is there?

The reverse (how do you know if someone's still using the driver) is equally hard to determine.

James

Krzysztof Halasa

2006-12-17 21:18 UTC #8 lore raw

Quoted 3 lines · James Bottomley

One of the touted benefits of Linux is that we run on old hardware. Unless the driver is demonstrably wrong (and they do become so as the APIs evolve)

Sure, I expect they do - but nobody is able to check.

Quoted 2 lines

The reverse (how do you know if someone's still using the driver) is equally hard to determine.

Sure. That's way I asked if we could make it easier.

Signature · 1 line

Krzysztof Halasa

Arjan van de Ven

2006-12-18 11:41 UTC #9 lore raw

Quoted 7 lines · Krzysztof Halasa

Quoted 3 lines · James Bottomley
One of the touted benefits of Linux is that we run on old hardware. Unless the driver is demonstrably wrong (and they do become so as the APIs evolve)
Sure, I expect they do - but nobody is able to check.

if a tree falls in a forest but there's nobody around to hear it, does it make a sound?

This sort of heisenbug questions aren't solved by "nobody hears it so lets chop down the forest to make houses out of the wood" answers...

Signature · 2 lines

if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Krzysztof Halasa

2006-12-18 13:48 UTC #10 lore raw

Quoted 5 lines · Arjan van de Ven

if a tree falls in a forest but there's nobody around to hear it, does it make a sound?
This sort of heisenbug questions aren't solved by "nobody hears it so lets chop down the forest to make houses out of the wood" answers...

Does that mean you don't want to know which hardware/drivers aren't used anymore and which ones are?

Signature · 1 line

Krzysztof Halasa

Arjan van de Ven

2006-12-18 15:20 UTC #11 lore raw

Quoted 10 lines · Krzysztof Halasa

Quoted 5 lines · Arjan van de Ven
if a tree falls in a forest but there's nobody around to hear it, does it make a sound?
This sort of heisenbug questions aren't solved by "nobody hears it so lets chop down the forest to make houses out of the wood" answers...
Does that mean you don't want to know which hardware/drivers aren't used anymore and which ones are?

it means that IT DOESN'T MATTER.
* If it's entirely unused, we get no bugreports -> there is no problem.
* If it's used but good quality, we get no bugreports -> there is no problem

we can't distinguish the two. But.. in neither case is there a problem so why force anything? I know some people don't like Heisenberg uncertainty, but... personally for me if the effect is the same I couldn't care less.

Signature · 2 lines

if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org