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

Bart Van Assche
2019-06-13T15:39:27Z

On 6/13/19 8:35 AM, 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 ?

How about leaving out "on actual hardware" from my e-mail? What you
described sounds like valuable work to me. I think testing with qemu is
sufficient.

Bart.