Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[Takashi Iwai <tiwai@suse.de>]

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