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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2019-06-13 at 08:35 -0700, 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 virtual hardware testing is acceptable: most of the regressions
we get in old drivers from untested updates isn't anywhere near the
hardware interface handling code usually.  It's usually just an
unintended consequence of a well meaning update to the generic part of
the driver.  People who don't have the hardware and don't really
understand the driver rarely touch the core hardware handling pieces
... and if they do, we usually do demand a hardware test.

James