acornscsi: remove linked command support

The acornscsi driver was added in v2.1.88. It has always #undef-ed CONFIG_SCSI_ACORNSCSI_LINK near the top of acornscsi.c. And, just to be sure, it has also always triggered a preprocessor error if CONFIG_SCSI_ACORNSCSI_LINK was still defined. But, as far as I can see, it has never even been possible to set SCSI_ACORNSCSI_LINK through kconfig, or its predecessors, in the first place.

Let's remove the code involved.

Signed-off-by Paul Bolle <[email protected]>

---
Untested.

Also interesting: SCSI_ACORNSCSI_TAGGED_QUEUE can be set through kconfig, but its macro will be #undef-ed at the top of acornscsi.c. I suppose that #undef could be dropped.

And finally: CONFIG_ACORNSCSI_CONSTANTS has to be set manually. But if we'd just drop the CONFIG_ prefix acornscsi.c would become a pet peeve free zone.

  drivers/scsi/arm/acornscsi.c | 53 --------------------------------------------
  1 file changed, 53 deletions(-)

drivers/scsi/arm/acornscsi.c +0 -50

index 059ff477a398..2e797a367608 100644
@@ -62,13 +62,6 @@
   */
  #undef CONFIG_SCSI_ACORNSCSI_TAGGED_QUEUE
  /*
- * SCSI-II Linked command support.
- *
- * The higher level code doesn't support linked commands yet, and so the option
- * is undef'd here.
- */
-#undef CONFIG_SCSI_ACORNSCSI_LINK
-/*
   * SCSI-II Synchronous transfer support.
   *
   * Tried and tested...

@@ -160,10 +153,6 @@
  #error "Yippee!  ABORT TAG is now defined!  Remove this error!"
  #endif
 
-#ifdef CONFIG_SCSI_ACORNSCSI_LINK
-#error SCSI2 LINKed commands not supported (yet)!
-#endif
-
  #ifdef USE_DMAC
  /*
   * DMAC setup parameters

@@ -1668,42 +1657,6 @@ void acornscsi_message(AS_Host *host)
  	}
  	break;
 
-#ifdef CONFIG_SCSI_ACORNSCSI_LINK
-    case LINKED_CMD_COMPLETE:
-    case LINKED_FLG_CMD_COMPLETE:
-	/*
-	 * We don't support linked commands yet
-	 */
-	if (0) {
-#if (DEBUG & DEBUG_LINK)
-	    printk("scsi%d.%c: lun %d tag %d linked command complete\n",
-		    host->host->host_no, acornscsi_target(host), host->SCpnt->tag);
-#endif
-	    /*
-	     * A linked command should only terminate with one of these messages
-	     * if there are more linked commands available.
-	     */
-	    if (!host->SCpnt->next_link) {
-		printk(KERN_WARNING "scsi%d.%c: lun %d tag %d linked command complete, but no next_link\n",
-			instance->host_no, acornscsi_target(host), host->SCpnt->tag);
-		acornscsi_sbic_issuecmd(host, CMND_ASSERTATN);
-		msgqueue_addmsg(&host->scsi.msgs, 1, ABORT);
-	    } else {
-		struct scsi_cmnd *SCpnt = host->SCpnt;
-
-		acornscsi_dma_cleanup(host);
-
-		host->SCpnt = host->SCpnt->next_link;
-		host->SCpnt->tag = SCpnt->tag;
-		SCpnt->result = DID_OK | host->scsi.SCp.Message << 8 | host->Scsi.SCp.Status;
-		SCpnt->done(SCpnt);
-
-		/* initialise host->SCpnt->SCp */
-	    }
-	    break;
-	}
-#endif
-
      default: /* reject message */
  	printk(KERN_ERR "scsi%d.%c: unrecognised message %02X, rejecting\n",
  		host->host->host_no, acornscsi_target(host),

@@ -2825,9 +2778,6 @@ char *acornscsi_info(struct Scsi_Host *host)
  #ifdef CONFIG_SCSI_ACORNSCSI_TAGGED_QUEUE
      " TAG"
  #endif
-#ifdef CONFIG_SCSI_ACORNSCSI_LINK
-    " LINK"
-#endif
  #if (DEBUG & DEBUG_NO_WRITE)
      " NOWRITE (" __stringify(NO_WRITE) ")"
  #endif

I'm all for it. Removing never-really-implemented feature on obsolete hardware is always a good idea.

Acked-by Hannes Reinecke <[email protected]>

Wait, no, that's not a good idea. We leave obsolete drivers to bitrot. Particularly we try not to touch them unless we have to because there might be a few people still using them and the more we tamper, the greater the risk that something gets broken.

On that principle, since
there's no real reason to remove the code,

it should stay ... until the
whole driver bitrots to the extent that we can no-longer compile it.

However, I'll do this if the Maintainer (rmk) acks ... because if it breaks he gets to fix it.

Quoted 4 lines · James Bottomley

Wait, no, that's not a good idea. We leave obsolete drivers to bitrot. Particularly we try not to touch them unless we have to because there might be a few people still using them and the more we tamper, the greater the risk that something gets broken.

Which is also a way to notice whether people still use those obsolete drivers.

Quoted 2 lines

On that principle, since
there's no real reason to remove the code,

(Unless one carries the hope that any check, treewide, for a CONFIG_* macro can be linked to a proper Kconfig symbol.)

Quoted 2 lines

it should stay ... until the
whole driver bitrots to the extent that we can no-longer compile it.

I've run into this depreciation policy before. With aic7xxx_old (which I eventually convinced Fedora to disable, a few relases before it was removed from the tree). With aic94xx (which I also convinced Fedora to disable). I also tried multiple times to shut up advansys' compile time[1]. It seems SCSI might risk not to notice their bitrot, because eventually everybody stops compiling these obsolete drivers, leaving SCSI without feedback on their state.

Anyhow, SCSI seems to be the only subsystem that uses this subcategory of not-really-maintained drivers. Other subsystems appear to allow anything to be fixed, even trivialities, which are what I tend to fix, and only stop allowing fixes if the drivers involved are going to be removed anyway. But maybe I just never ran into that category in other subsystems.

Quoted 6 lines · Paul Bolle

Quoted 4 lines · James Bottomley

Wait, no, that's not a good idea. We leave obsolete drivers to bitrot. Particularly we try not to touch them unless we have to because there might be a few people still using them and the more we tamper, the greater the risk that something gets broken.

Quoted 2 lines

Which is also a way to notice whether people still use those obsolete drivers.

Really, no. We don't deliberately break old drivers to see if anyone notices. Usually the feedback loop is months to years for the long tail to notice and by that time fixing the problem becomes a real pain if you allow driver churn.

We keep old drivers that compile until there's a problem caused usually by something like API changes.

Quoted 3 lines

Quoted 2 lines

On that principle, since
there's no real reason to remove the code,

Quoted 2 lines

(Unless one carries the hope that any check, treewide, for a CONFIG_* macro can be linked to a proper Kconfig symbol.)

The check can be fixed. If you look at what Fengguang Wu does, he has a list of expected problems which he diffs. Don't churn the tree to match the checker, make the checker match the tree.

Quoted 10 lines

Quoted 2 lines

it should stay ... until the
whole driver bitrots to the extent that we can no-longer compile it.

I've run into this depreciation policy before. With aic7xxx_old (which I eventually convinced Fedora to disable, a few relases before it was removed from the tree). With aic94xx (which I also convinced Fedora to disable). I also tried multiple times to shut up advansys' compile time[1]. It seems SCSI might risk not to notice their bitrot, because eventually everybody stops compiling these obsolete drivers, leaving SCSI without feedback on their state.

Why would we care? If it compiles that's fine, it's not causing a problem and it might just be useful to somebody.

The time obsolete drivers cause problems is tree or subsystem wide API changes. Then we look at the amount of work required and sometimes remove them or do hack fixes.

Quoted 6 lines

Anyhow, SCSI seems to be the only subsystem that uses this subcategory of not-really-maintained drivers. Other subsystems appear to allow anything to be fixed, even trivialities, which are what I tend to fix, and only stop allowing fixes if the drivers involved are going to be removed anyway. But maybe I just never ran into that category in other subsystems.

Try ide ... they have the same policy.

Try to understand the reason: we have a long tail of people using obsolete systems who we try not to break. Any change to an unmaintained driver which can't be tested risks that ... and I'm the one who would have to try to sort out the problem when it's noticed, hence the caution. If we allow trivial churn, by the time the breakage is noticed (usually months to years later), the driver will have picked up a ton of changes and finding the problem one becomes really hard. So unmaintained drivers get a default deep freeze maintenance policy.

The acornscsi driver was added in v2.1.88. It has always #undef-ed CONFIG_SCSI_ACORNSCSI_LINK near the top of acornscsi.c. And, just to be sure, it has also always triggered a preprocessor error if CONFIG_SCSI_ACORNSCSI_LINK was still defined. But, as far as I can see, it has never even been possible to set SCSI_ACORNSCSI_LINK through kconfig, or its predecessors, in the first place.

Let's remove the code involved.

Signed-off-by Paul Bolle <[email protected]>

Quoted 10 lines · Paul Bolle

The acornscsi driver was added in v2.1.88. It has always #undef-ed CONFIG_SCSI_ACORNSCSI_LINK near the top of acornscsi.c. And, just to be sure, it has also always triggered a preprocessor error if CONFIG_SCSI_ACORNSCSI_LINK was still defined. But, as far as I can see, it has never even been possible to set SCSI_ACORNSCSI_LINK through kconfig, or its predecessors, in the first place.

Let's remove the code involved.

Signed-off-by Paul Bolle <[email protected]>

Looks good,

Reviewed-by Christoph Hellwig <[email protected]>

And I have to disagree with James here, removing code that isn't even compiled always is an improvement, especially for an unmaintained driver.

Quoted 7 lines · Christoph Hellwig

Looks good,

Reviewed-by Christoph Hellwig <[email protected]>

And I have to disagree with James here, removing code that isn't even compiled always is an improvement, especially for an unmaintained driver.

Well, as I said, this is in theory a maintained driver, so just get an ack from Russell and this debate is moot.