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

Guenter Roeck
2019-06-13T15:35:15Z

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