| Message ID | 1400926433.31526.89.camel@x220 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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.)
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
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.
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
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>
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
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
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(-)