On Mon, 4 Jan 2021, Bart Van Assche wrote: > 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. > That suggests to me that the code that you're hoping to remove 1) has no bugs, or 2) has no reported bugs, or 3) has no users at present. I am confident that your evidence does not support your conclusion (i.e. the code will never be used again). Sometimes, users only appear after the unreported bugs get fixed. I've seen it happen. > > 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. I'm unaware of such an obligation. API changes happen often. When they do, we see good test coverage of commercially viable hardware, some best-effort testing of common hardware, and some perfunctory build testing. But that is missing the point, which was about a particular driver, not about development process. You have not shown how the target API is special, to support your claim that this driver imposes an unreasonable burden. In the interests of making forward progress in this discussion, shall we discuss the kind of SCSI Target API changes that you anticipate? > 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. > Keeping _any_ driver in the kernel involves a maintenance burden. There are two good ways to address that. Firstly, by improving the development process. For example, an API change is mostly mechanical work that lends itself to automated refactoring. Secondly, by involving all interested parties, so that the burden is shared. Of course, there are other ways. E.g. "don't ship code when doing so won't turn a profit". That, by the way, was the policy that gave us 10 billion Android devices (or more) that don't function with a mainline kernel. > 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, ...). > Ethernet is not always an alternative. That was already discussed in this thread. But let's assume for a moment that you can migrate any and all users of this driver over to an ethernet driver. Why would the maintainers of that ethernet driver and its API accept that plan, if adding users would extend their maintenance and testing obligations? Do you think those maintainers should pay the "kind of tax that all developers/users pay to all developers/users?" > Thanks, > > Bart. >
