linux-kernel - Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

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:   Mon, 4 Jan 2021 09:43:46 -0800
From:   Bart Van Assche <bvanassche@....org>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Chris Boot <bootc@....tc>, linuxppc-dev@...ts.ozlabs.org,
        target-devel@...r.kernel.org, linux-scsi@...r.kernel.org,
        linux1394-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org, Chuhong Yuan <hslester96@...il.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        Nicholas Bellinger <nab@...ux-iscsi.org>,
        Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

On 6/16/20 7:07 PM, Finn Thain wrote:
> 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.

(replying to an e-mail from six months ago)

Hi Finn,

I am confident that my estimate is an accurate estimate since I have not
seen any sbp support requests, sbp bug reports nor any sbp bug fixes since
the sbp target driver has been accepted upstream.

> 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?

Yes. If anyone wants to change the interface between SCSI target core and
SCSI target drivers, all target drivers, including the sbp and FCoE target
driver have to be retested. In other words, keeping unused target drivers
inside the kernel tree involves a significant maintenance burden for anyone
who wants to modify the interface between the SCSI target core and SCSI
target drivers.

Additionally, there is a good alternative available for the sbp driver.
Every system I know of that is equipped with a Firewire port also has an
Ethernet port. So users who want to provide SCSI target functionality on
such systems can use any SCSI transport protocol that is compatible with
Ethernet (iSCSI, iSER over soft-RoCE, SRP over soft-RoCE, ...).

Thanks,

Bart.