From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751859AbdK1IUi (ORCPT ); Tue, 28 Nov 2017 03:20:38 -0500 Received: from mout.web.de ([212.227.15.4]:62187 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750839AbdK1IUg (ORCPT ); Tue, 28 Nov 2017 03:20:36 -0500 Subject: Re: ALSA: nm256: Fine-tuning for three function implementations To: Takashi Iwai , alsa-devel@alsa-project.org Cc: Arvind Yadav , Jaroslav Kysela , Takashi Sakamoto , kernel-janitors@vger.kernel.org, LKML References: <24f8c777-1eb4-e7e7-9371-79f32700c9dc@users.sourceforge.net> From: SF Markus Elfring Message-ID: <2cbef557-5f89-c630-e108-14ef2ce6b41a@users.sourceforge.net> Date: Tue, 28 Nov 2017 09:19:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:FOK7UfHM4w0zcc9wNHulVFx5Aggxocqyf078s9xiu/498Ryw8Ut qJdX9LgZz8ZSBoUi9X7n5WvqGh+6VEqtuuFIXvcFPObXqOt8oVlG9PXes8sCWlDsABzdtKb FWobaMeBJ7SzdiggoKl4S0JG2jmDVFrHUdQKqRRp0SA9sDcdfFiXn6LAvV7MfnbIKLbA/89 Ddfrj1q469FXnceCRvBvA== X-UI-Out-Filterresults: notjunk:1;V01:K0:7A/EML5myAk=:zR/tv1Hodu2IZUQjDGcEbu AsGc7tCSzfDa3XbDPGnHjgMrhtlWlcsm+I8Oi0P1h5ijNVGWzBSmHxSQcImZCvSYtFuDdiNAe wreQ70Y2PegGlcSrf+gqpxa+1Qvrn/UizVAzoO9zgk/nFiBLS1Y1BX8JsgIYFarDWFq29j5GM KMw3oKR98HriqWgG4BjQQtm7UDmjEFdIUOSsq3UKNyDupwEVUvMs6hsSvPVLeKiGdOqKB5de9 NUmt9nQw9B95cv4LzLzNALT9azVUJ/RxroOD+fwS6P6BGekIFl34dFyAlZeYv8UlvFfCtOeSt 9Nx5praeoktNSi07FiczxfmPCNlO5EKWxhC1h/Z8+6h/BvI8EFw8dlZUUn8EPqjp/KAtUTBgO OmnprtzMdr9doXSDTe9UHoVFPBcLZmcZ1cx5VchofC5xUpPxzK3bJlvdrQ5z8A6mZo3gNNb2P i1VGJaIzXQxrLSNQ+sGr+oARb3mG6WLoWw50AEaLaUZis/woEl2MPTYK4jSJIWi/NpVh9dsPC fKO6nKgc1Y89vUe8U9M6D6maZYSvYSwAnwSKaRoksPpEkb+5hbhFP5BVlCDIU4xnBTHSUc6Gl rjKPmAzVBL1y3rb5HmO8pRQmYfaSV14AyL8DejPTdOqAgzeRg8G5OQAGTRm/SmUs4pyZTRTaT Zs8yRFfco5+6B/P1oiWLaqPqw/FjHa+rct2KAF8bJj2gQQs4PdlRLtr/9rdo05N92oQZfjKYk iSOlmjX8eag7txHiqxqCBzXvBv2lnP34pgqMkr65BayoNUV1THH1+n0VDFl/LXAL/DjUX7oB6 Jlah5DeXxne0pTLWuT4EvIA2Sx4cWRa+ZMCvrSKqtFBBM7gy70= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>> 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. There can be additional means be used to reduce the probability of undesired side effects. > It must be "almost perfect" for such a code refactoring. Can you get the impression that the shown transformation patterns were correctly applied for the source file “sound/pci/nm256/nm256.c”? > The damage by a overseen mistake is much higher than the merit by such a patch. Are there any more software developers and code reviewers available who would like to point another programming mistake out for this Linux module? > If the patch is about fixing a bug, it's a different story. How do “deviations” from the coding style and the evolution of object code size fit to this view here? > Or it's about a really trivial change (e.g. your sizeof() conversion > patches), I can check and apply easily. My update selection can contain also trivial adjustments. > But for other changes with more lines, it makes little sense. Do you need any more information to see and eventually accept the sense again? > Again, the risk of breakage increases while the merit is negligible. We disagree about corresponding benefits at the moment. Would any other contributors comment the situation a bit more? >>> -- 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 noticed that the development status of tools which you might find nice at the moment can be also questionable. > I stop at this point, as the rest is simply a repeat from the previous mail. Are you using a continuous integration system? Regards, Markus