lkml.org 
[lkml]   [2017]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations
On Thu, 16 Nov 2017 18:48:43 +0100,
SF Markus Elfring wrote:
>
> >> Two update suggestions were taken into account
> >> from static source code analysis.
> >
> > Markus, I'd apply this kind of patches only when they are really
> > tested on the hardware,
>
> I can not test all software and hardware combinations (so far)
> for which I dare to show change possibilities.
>
>
> > or they were converted systematically by a script like spatch.
>
> There is a general source code transformation pattern involved.
> So I find that it is systematic.
>
> But I did not dare to develop a script variant for the semantic patch
> language (Coccinelle software) which can handle all special use cases
> as a few of them are already demonstrated in this tiny patch series.

Then you're doing everything by hands, and can be wrong -- that's the
heart of the problem. The risk is bigger than the merit by applying
the patch.

So, just prove that your patch doesn't break anything. Doesn't matter
whether it's a test with real hardware or with systematic checks.
Once when it's confirmed, we can apply it. A very simple rule, and
this will be valid for most of other subsystems, too.


thanks,

Takashi

>
>
> > The reason is that you might break something
>
> There are the usual software development risks.
>
>
> > (and you already broke things in the past).
>
> I presented also some improvable update suggestions.
>
> Another look on the corresponding circumstances might be interesting
> for further clarification.
>
>
> > The merit by such a patch is negligible in comparison of the risk of breakage.
>
> I imagine that you might like a small object code reduction also for
> this software module.
>
>
> > These codes aren't too bad without fixing, after all;
> > everyone can read it pretty well as is.
>
> The script "checkpatch.pl" points implementation details out for
> further considerations.
>
>
> > If these patches were tested on a real hardware,
>
> I assume that this aspect can become a big challenge.
>
>
> > or at least on VM, so that you can show that they don't break anything,
>
> Which test results would you trust (from me)?
>
>
> > I'll happily apply them for the next (4.16) kernel.
>
> Thanks for your general offer.
>
>
> > Or, if you're really working on other real changes
>
> I would find a bit more efficient exception handling useful.
>
>
> > (no cosmetic coding style fixes nor the code shuffling,
>
> I propose to apply also corresponding checkpatch cosmetic.
>
>
> > but fixing a real bug)
>
> I am trying to adjust the software situation a bit more for better
> run time characteristics.
>
>
> > *and* such a cleanup is mandatory as preliminary, it can be accepted, too.
>
> There are change combinations needed for the proposed software
> design direction.
> Can you see positive effects here?
>
> Regards,
> Markus
>
\
 
 \ /
  Last update: 2017-11-17 17:18    [W:0.175 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site