From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 746D2D3B for ; Thu, 13 Jun 2019 15:35:15 +0000 (UTC) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2AB8163D for ; Thu, 13 Jun 2019 15:35:15 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id p1so8318942plo.2 for ; Thu, 13 Jun 2019 08:35:15 -0700 (PDT) Sender: Guenter Roeck To: Bart Van Assche , "Martin K. Petersen" , James Bottomley References: <1559836116.15946.27.camel@HansenPartnership.com> <20190606155846.GA31044@kroah.com> <1559838569.3144.11.camel@HansenPartnership.com> <20190613104930.7dc85e13@coco.lan> <1560436507.3329.12.camel@HansenPartnership.com> <3418df99-ff2b-9a9f-7702-1e272d1cb783@acm.org> From: Guenter Roeck Message-ID: <9623aa32-31f2-0053-d3bc-64bfb151865a@roeck-us.net> Date: Thu, 13 Jun 2019 08:35:11 -0700 MIME-Version: 1.0 In-Reply-To: <3418df99-ff2b-9a9f-7702-1e272d1cb783@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Cc: Mauro Carvalho Chehab , ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 6/13/19 8:21 AM, Bart Van Assche wrote: > On 6/13/19 8:03 AM, Martin K. Petersen wrote: >> >> James, >> >>> It depends: every patch you do to an old driver comes with a risk of >>> breakage.  What we've found is even apparently sane patches cause >>> breakage which isn't discovered until months later when someone with >>> the hardware actually tests. >> >> My pet peeve is with the constant stream of seemingly innocuous >> helper-interface-of-the-week changes. Such as "Use kzfoobar() instead of >> kfoobar() + memset()". And then a year later somebody decides kzfoobar() >> had a subtle adverse side-effect and now we all need to switch to >> kpzfoobar(). >> >> I appreciate that some of these helpers may have merit in terms of >> facilitating static code checkers, etc. But other than that, I really >> fail to see the value of this constant churn. >> >> The devil is always in the details. It's almost inevitably these obvious >> five-liners that cause regressions down the line. >> >> So why do we keep doing this? > > How about discussing at the kernel summit whether or not patches that have not been tested on actual hardware should be ignored? > A while ago I spent some time writing unit tests for various i2c based hwmon drivers (https://github.com/groeck/module-tests). With those, I found a substantial number of overflow conditions and other problems in various drivers. Similar, my qemu boot tests have identified several problems over time, by nature of qemu often on hardware which is difficult if not almost impossible to find nowadays (ohci-sm501 is a current example). Are you saying that such problems should not be fixed unless they can be verified on real hardware ? Guenter