lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 24 May 2014 15:16:35 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Hannes Reinecke <hare@...e.de>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ