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.
