From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760876AbdKPSyo (ORCPT ); Thu, 16 Nov 2017 13:54:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:57358 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751413AbdKPSyg (ORCPT ); Thu, 16 Nov 2017 13:54:36 -0500 Date: Thu, 16 Nov 2017 19:54:34 +0100 Message-ID: From: Takashi Iwai To: SF Markus Elfring Cc: alsa-devel@alsa-project.org, Arvind Yadav , Jaroslav Kysela , Takashi Sakamoto , kernel-janitors@vger.kernel.org, LKML Subject: Re: [PATCH 0/2] ALSA: nm256: Fine-tuning for three function implementations In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >