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

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

On Thu, 2019-06-13 at 11:03 -0400, 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?

Heh, this reminds me a lot of the module section annotations (you
remember, things like __devinit).  We built a huge tooling system which
allowed hundreds of patches to "fix" the problems for obscure Kconfig
values.  Simply eliminating the lot was a huge relief and no-one at all
has missed it ever ... it was basically a huge make-work patch
generation system.

Perhaps the time has come to require justification of replacing
kmalloc/memset with kzalloc ... I don't think the pattern is hugely
bad, but if it doesn't improve anything the code, why do it?

So what I'd like to see is instead of simply "Coccinelle found this so
I'm sending a patch" require something like "Coccinelle found this and
it occurs in the fast path where using architecturally cleared memory
results in a 5% speed up of the code".

James