Re: [PATCH] acornscsi: remove linked command support
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 > > > > 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 -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 > > Looks good, > > Reviewed-by: Christoph Hellwig > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 Looks good, Reviewed-by: Christoph Hellwig And I have to disagree with James here, removing code that isn't even compiled always is an improvement, especially for an unmaintained driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 pebo...@tiscali.nl Looks good, Reviewed-by: Christoph Hellwig h...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 pebo...@tiscali.nl Looks good, Reviewed-by: Christoph Hellwig h...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 h...@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+ker...@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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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
---
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(>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
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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
---
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(>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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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 pebo...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 pebo...@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 h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@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)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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 h...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
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.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
