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

Leon Romanovsky
2019-06-14T11:53:47Z

On Thu, Jun 13, 2019 at 08:39:22AM -0700, Bart Van Assche wrote:
> 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.

There are kernel subsystems without available QEMU virtual hardware
or with special hardware which is not available for most of the active
developers. Sometimes bugs in those drivers stop whole subsystem for
moving forward and needed to be fixed without HW.

Thanks

>
> Bart.
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss