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 1C050DC2 for ; Thu, 13 Jun 2019 15:42:33 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8CCAE711 for ; Thu, 13 Jun 2019 15:42:32 +0000 (UTC) Date: Thu, 13 Jun 2019 17:42:30 +0200 Message-ID: From: Takashi Iwai To: Guenter Roeck In-Reply-To: <9623aa32-31f2-0053-d3bc-64bfb151865a@roeck-us.net> 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> <9623aa32-31f2-0053-d3bc-64bfb151865a@roeck-us.net> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: James Bottomley , Mauro Carvalho Chehab , ksummit , Bart Van Assche 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 Thu, 13 Jun 2019 17:35:11 +0200, Guenter Roeck wrote: > > 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 ? I think the issue here is about cleanup patches, which are supposedly safe but often aren't. thanks, Takashi