[PATCH] acornscsi: remove linked command support

[PATCH] acornscsi: remove linked command support

[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 <pebolle@tiscali.nl>
---
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(-)

diff --git a/drivers/scsi/arm/acornscsi.c b/drivers/scsi/arm/acornscsi.c
index 059ff477a398..2e797a367608 100644
--- a/drivers/scsi/arm/acornscsi.c
+++ b/drivers/scsi/arm/acornscsi.c
@@ -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
@@ -2851,9 +2801,6 @@ static int acornscsi_show_info(struct seq_file *m, struct Scsi_Host *instance)
 #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
-- 
1.9.0

Re: [PATCH] acornscsi: remove linked command support

[Hannes Reinecke]

On 05/24/2014 12:13 PM, Paul Bolle wrote:
> 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 <pebolle@tiscali.nl>
> ---
> 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(-)
>
> diff --git a/drivers/scsi/arm/acornscsi.c b/drivers/scsi/arm/acornscsi.c
> index 059ff477a398..2e797a367608 100644
> --- a/drivers/scsi/arm/acornscsi.c
> +++ b/drivers/scsi/arm/acornscsi.c
> @@ -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
> @@ -2851,9 +2801,6 @@ static int acornscsi_show_info(struct seq_file *m, struct Scsi_Host *instance)
>   #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 <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: [PATCH] acornscsi: remove linked command support

[James Bottomley]

On Sat, 2014-05-24 at 12:35 +0200, Hannes Reinecke wrote:
[...]
> I'm all for it. Removing never-really-implemented feature on obsolete 
> hardware is always a good idea.
> 
> Acked-by: Hannes Reinecke <hare@suse.de>

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.

James

Re: [PATCH] acornscsi: remove linked command support

[Paul Bolle]

On Sat, 2014-05-24 at 16:13 +0400, James Bottomley wrote:
> 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.

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

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

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


Paul Bolle

[1] advansys prints a pointless compile time warning, on purpose.
Clearly no one cares about its "wide board" support, but for some reason
that warning needs to stay in. (Fedora declined to disable that driver.)

Re: [PATCH] acornscsi: remove linked command support

[James Bottomley]

On Sat, 2014-05-24 at 15:16 +0200, Paul Bolle wrote:
> On Sat, 2014-05-24 at 16:13 +0400, James Bottomley wrote:
> > 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.

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.

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

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.

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

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

Even for a maintained driver, if the maintainer has little access to the
hardware and few users they may also choose a deep freeze maintenance
policy for the same reasons above; that's why no changes without
maintainer ack.

James

Re: [PATCH] acornscsi: remove linked command support

[Christoph Hellwig]

On Sat, May 24, 2014 at 12:13:53PM +0200, Paul Bolle wrote:
> 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 <pebolle@tiscali.nl>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

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

Re: [PATCH] acornscsi: remove linked command support

[James Bottomley]

On Wed, 2014-05-28 at 03:41 -0700, Christoph Hellwig wrote:
> On Sat, May 24, 2014 at 12:13:53PM +0200, Paul Bolle wrote:
> > 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 <pebolle@tiscali.nl>
> 
> Looks good,
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> 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.

James

Re: [PATCH] acornscsi: remove linked command support

[Russell King - ARM Linux]

On Wed, May 28, 2014 at 06:26:44PM +0400, James Bottomley wrote:
> On Wed, 2014-05-28 at 03:41 -0700, Christoph Hellwig wrote:
> > Looks good,
> > 
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > 
> > 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.

I don't see any harm in removing this - I don't think I've owned any
SCSI devices which supported linked commands, which is why I never
put much effort into it.  As no one else seems to care about it (given
the number of years it's been left alone), removing the linked command
stuff is fine.

Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH] acornscsi: remove linked command support

[Paul Bolle]

On Sun, 2014-05-25 at 11:42 +0400, James Bottomley wrote:
> On Sat, 2014-05-24 at 15:16 +0200, Paul Bolle wrote:
> > On Sat, 2014-05-24 at 16:13 +0400, James Bottomley wrote:
> > > 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.
> 
> 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.

Of course I wasn't advocating deliberately breaking old drivers. But
it's easy to get annoyed by that short remark. It would have been better
if I hadn't made it.

Especially because I didn't also point out, as Cristoph did, that the
code I want removed doesn't get compiled. So removing it can, by
definition I'd say, not break that old driver.

> We keep old drivers that compile until there's a problem caused usually
> by something like API changes.
> 
> > > 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.)
> 
> 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.

Sure. See my recent patch to scripts/headers_check.pl, which does just
that. But before one special cases a certain hit for a checker one needs
to know that this hit really can't or won't be fixed. And in order to
know that one needs to at least try to fix it first.

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

Fair point: having code that no one uses doesn't cost a lot.

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

I never really touched IDE. That might explain why I only ran into this
issue with SCSI.

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

Thanks for taking the time to explain this to me. I appreciate that.
This is the first time, I think, that I've seen you explain that policy.
(I might have missed earlier explanations to other people.) Now I might
not entirely agree with you, but it does help to know where you're
coming from.

Thanks,


Paul Bolle