Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp138451ybt; Tue, 16 Jun 2020 19:10:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLHEefZ5Qj4WkLjnSagXsmQMBhTy+AEUwisI0m4KiNB+6trg6LaJbJCMr2V0wxlYxTLpup X-Received: by 2002:a17:906:7802:: with SMTP id u2mr5598987ejm.478.1592359802307; Tue, 16 Jun 2020 19:10:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592359802; cv=none; d=google.com; s=arc-20160816; b=p1UaeD2OGyzyJH64pQarTVxEST9rEQnpU3Ze95Zs3M+sOLGyUwOBPL2hA1D//jWdqW GKOiGDnUgtXD+W4NYDZEsoD9OHXO1Uvd+J4HltU2o0VrlfSPQCMKtBiQQuq0ubmuu3BC tUIa56cfwWMGB6ZNPUBHIKf4w5ORYblQmrAELjl4naTzdZjEsxnC6bm97suP8VDSe8wg 3NXXolAAtlbMSTQWl5H7tqrx0v5KetXfTJFPcBo0TjCstZGsjwChesNkBR/1w3hWgGcC 2dFyzn7rGuVYZ2KM1r8X2reComYKkWhj6y8A2KiNfQ9ZhegfBcUfGhUFp86v4ZAHZGHF KMNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=Hs6NFe2CDFVtjH2HijbZhlRUqU74fn08fX9dw89F6VI=; b=Dsd1rj/m+LXsjdGMnddpGERD07xShglAhdFnesI9HmlLXvhV7ByNBdxOKSXi2U1Bgo 48D1I8pSGWucxjKaDJMnMp6pgc2RQd6Sjom6hpFLjlh6vP61jj8cpW1dm9+pqR7nU6D+ HP9EULDXdBuCbK25PgFxzF/JT+l6GdyX0aIsooRnrl9Y147jAtXvl7xmVkPBgFFHOJ18 l3L16H3I2oGWRTJkwL9fKJMciXRfU+7Nj2TZcwJEbcT51PUd6Kjyxchi3NeUe+kCEHOg ofDH1YKI20bbFcjvnHmpjr3NYgsuU6uu2KXzWRNJ4kMIKkYXNlaJVBdw7p9iexIaVtiv e2qg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e18si11317896eds.250.2020.06.16.19.09.37; Tue, 16 Jun 2020 19:10:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726601AbgFQCHr (ORCPT + 99 others); Tue, 16 Jun 2020 22:07:47 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:38788 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726253AbgFQCHp (ORCPT ); Tue, 16 Jun 2020 22:07:45 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id 08FB82787E; Tue, 16 Jun 2020 22:07:38 -0400 (EDT) Date: Wed, 17 Jun 2020 12:07:40 +1000 (AEST) From: Finn Thain To: Bart Van Assche cc: Chris Boot , linuxppc-dev@lists.ozlabs.org, target-devel@vger.kernel.org, linux-scsi@vger.kernel.org, linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chuhong Yuan , "Martin K . Petersen" , Nicholas Bellinger , Stefan Richter Subject: Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver In-Reply-To: <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org> Message-ID: References: <01020172acd3d10f-3964f076-a820-43fc-9494-3f3946e9b7b5-000000@eu-west-1.amazonses.com> <7ad14946-5c25-fc49-1e48-72d37a607832@boo.tc> <8da0c285-d707-a3d2-063e-472af5cc560f@boo.tc> <8cbab988-fba7-8e27-7faf-9f7aa36ca235@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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