From: Takashi Iwai <tiwai@suse.de>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: alsa-devel@alsa-project.org,
Arvind Yadav <arvind.yadav.cs@gmail.com>,
Jaroslav Kysela <perex@perex.cz>,
Takashi Sakamoto <o-takashi@sakamocchi.jp>,
kernel-janitors@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations
Date: Thu, 16 Nov 2017 19:54:34 +0100 [thread overview]
Message-ID: <s5h7euq9hqt.wl-tiwai@suse.de> (raw)
In-Reply-To: <dfa99045-f213-3dad-b1f4-2e90eb38ddbd@users.sourceforge.net>
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
>
next prev parent reply other threads:[~2017-11-16 18:54 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 17:05 [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations SF Markus Elfring
2017-11-16 17:07 ` [PATCH 1/2] ALSA: nm256: Adjust five function calls together with a variable assignment SF Markus Elfring
2017-11-16 17:08 ` [PATCH 2/2] ALSA: nm256: Use common error handling code in snd_nm256_probe() SF Markus Elfring
2017-11-16 17:15 ` [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations Takashi Iwai
2017-11-16 17:48 ` SF Markus Elfring
2017-11-16 18:54 ` Takashi Iwai [this message]
2017-11-16 19:30 ` SF Markus Elfring
2017-11-28 7:46 ` Takashi Iwai
2017-11-28 8:19 ` SF Markus Elfring
2017-11-28 9:10 ` Takashi Iwai
2017-11-28 9:50 ` SF Markus Elfring
2017-11-28 11:37 ` Takashi Iwai
2017-11-28 12:33 ` SF Markus Elfring
2017-11-28 12:46 ` Takashi Iwai
2017-11-28 13:00 ` SF Markus Elfring
2017-11-28 13:06 ` Takashi Iwai
2017-11-28 13:17 ` SF Markus Elfring
2017-11-28 13:38 ` Takashi Iwai
2017-11-28 14:19 ` SF Markus Elfring
2017-11-28 14:27 ` Takashi Iwai
2017-11-28 14:33 ` SF Markus Elfring
2017-11-28 14:38 ` Takashi Iwai
2017-11-28 14:44 ` SF Markus Elfring
2017-11-28 14:53 ` Takashi Iwai
2017-11-28 15:01 ` SF Markus Elfring
2017-11-28 15:21 ` Takashi Iwai
2017-11-28 16:15 ` SF Markus Elfring
2017-11-28 16:27 ` Takashi Iwai
2017-11-28 16:40 ` SF Markus Elfring
2017-11-28 16:44 ` Takashi Iwai
2017-11-28 17:15 ` SF Markus Elfring
2017-11-28 18:35 ` Takashi Iwai
2017-11-28 19:08 ` SF Markus Elfring
2017-11-28 19:43 ` Takashi Iwai
2017-11-28 19:48 ` SF Markus Elfring
2017-11-28 19:54 ` Takashi Iwai
2017-11-28 19:57 ` SF Markus Elfring
2017-11-28 20:00 ` Takashi Iwai
2017-11-28 20:18 ` SF Markus Elfring
2017-11-28 20:25 ` Takashi Iwai
2017-11-28 20:32 ` SF Markus Elfring
2017-11-29 10:34 ` SF Markus Elfring
2017-11-28 12:33 ` [alsa-devel] " Ondrej Zary
2017-11-28 13:10 ` SF Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5h7euq9hqt.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=arvind.yadav.cs@gmail.com \
--cc=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
--cc=perex@perex.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).