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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/