From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751977AbdK1HqX (ORCPT ); Tue, 28 Nov 2017 02:46:23 -0500 Received: from mx2.suse.de ([195.135.220.15]:33080 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751900AbdK1HqU (ORCPT ); Tue, 28 Nov 2017 02:46:20 -0500 Date: Tue, 28 Nov 2017 08:46:17 +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: ALSA: nm256: Fine-tuning for three function implementations In-Reply-To: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net> References: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net> 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=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Nov 2017 20:30:24 +0100, SF Markus Elfring wrote: > > >> 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, > > I am navigating through possible changes around the pattern > “Use common error handling code” mostly manually so far. > > > > and can be wrong > > Such a possibility remains as usual. "As usual" doesn't suffice. It must be "almost perfect" for such a code refactoring. The damage by a overseen mistake is much higher than the merit by such a patch. If the patch is about fixing a bug, it's a different story. Or it's about a really trivial change (e.g. your sizeof() conversion patches), I can check and apply easily. But for other changes with more lines, it makes little sense. Again, the risk of breakage increases while the merit is negligible. > > -- that's the heart of the problem. > > There might be related opportunities for further improvements. > Do you trust adjustments from an evolving tool more than > my concrete contributions? Yes, loudly. I stop at this point, as the rest is simply a repeat from the previous mail. thanks, Takashi