From: Paul Bolle <pebolle@tiscali.nl>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Hannes Reinecke <hare@suse.de>,
Russell King <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] acornscsi: remove linked command support
Date: Sat, 24 May 2014 15:16:35 +0200 [thread overview]
Message-ID: <1400937395.22523.55.camel@x220> (raw)
In-Reply-To: <1400933617.6956.34.camel@dabdike.int.hansenpartnership.com>
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.)
next prev parent reply other threads:[~2014-05-24 13:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-24 10:13 [PATCH] acornscsi: remove linked command support Paul Bolle
2014-05-24 10:35 ` Hannes Reinecke
2014-05-24 12:13 ` James Bottomley
2014-05-24 13:16 ` Paul Bolle [this message]
2014-05-25 7:42 ` James Bottomley
2014-05-28 17:28 ` Paul Bolle
2014-05-28 10:41 ` Christoph Hellwig
2014-05-28 14:26 ` James Bottomley
2014-05-28 15:17 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1400937395.22523.55.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hare@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).