[PATCH] scsi: target/sbp: remove firewire SBP target driver
Finn Thain
fthain at telegraphics.com.au
Wed Jun 17 12:07:40 AEST 2020
On Tue, 16 Jun 2020, Bart Van Assche wrote:
>
> As far as I know the sbp driver only has had one user ever and that user
> is no longer user the sbp driver.
So, you estimate the userbase at zero. Can you give a confidence level?
Actual measurement is hard because when end users encounter breakage, they
look for quick workarounds before they undertake post mortem, log
collection, bug reporting, mailing list discussions, analysis etc.
> So why to keep it in the kernel tree?
Answer: for the same reason it was added to the tree.
Here's a different question: "Why remove it from the kernel tree?"
If maintaining this code is a burden, is it not the kind of tax that all
developers/users pay to all developers/users? Does this driver impose an
unreasonably high burden for some reason?
The growth of a maintenance burden in general has lead to the invention of
design patterns and tooling to minize it. So a good argument for removal
would describe the nature of the problem, because some driver deficiencies
can be fixed automatically, and some tooling deficiencies can compound an
otherwise insignificant or common driver deficiency.
There are spin-off benefits from legacy code besides process improvements.
Building and testing this sort of code has regularly revealed erroneous
corner cases in commits elsewhere like API changes and refactoring.
Also, legacy code is used by new developers get experience in code
modernization. And it provides more training material for neural networks
that need to be taught to recognize patches that raise quality.
Ten or twenty years ago, I doubt that anyone predicted these (and other)
spin-off benefits. If we can't predict the benefit, how will we project
the cost, and use that to justify deletion?
Please see also,
http://www.mac.linux-m68k.org/docs/obsolete.php
More information about the Linuxppc-dev
mailing list