From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752401AbdK1JvN (ORCPT ); Tue, 28 Nov 2017 04:51:13 -0500 Received: from mout.web.de ([212.227.15.14]:53404 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751603AbdK1JvH (ORCPT ); Tue, 28 Nov 2017 04:51:07 -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> <2cbef557-5f89-c630-e108-14ef2ce6b41a@users.sourceforge.net> From: SF Markus Elfring Message-ID: <1547a4c2-5b70-e3a3-b482-d28c538e615c@users.sourceforge.net> Date: Tue, 28 Nov 2017 10:50:21 +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:htk602Suy7RrefzitwFHhx1dkwFAxIcWkJg5PJ10VAIfS8UvNLM Uw7X2MKt2QaPKo52etPKJjeTYXWDnkGVvsys3TxOTFFVcsxHjHxYxn32iD2tvQgSm9SpF6F 7zJeIlgIYkVofFzBTsPlJoRYhT2RSWPaVP2WC2r+xq0LfzmxHNkQT1/eBuLTWMAJ0tc8ahN YQN3sQ9hHM6nsnJ6uRcuQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:bxD6d+ycSa4=:BwRwS9QB4yr1AZDO8/NidJ G+LWmr8g3evhVSf5hbN1ugGcN7AYA4l2Dmv8KaT8+f8cxaqcQl8jGgewRi8CkRZ6N+IoYUgeg 9dygKdfaLiWP5RJaCsglbLTaNas4F1J78Ebo/aUG+TnvTi57ylEuGWEVUtefk3TWoaGf/6qe2 Re09ig+EUV9mAPoM8zk2QQJncxEkxFGTxSyZ5fBfWL9SEd2PtvvFckrH6z/L+yOl+xycovecr MFoDL2Jjnj08jeBfqZPjQMdisRRvoSKdG3YsYFcyn22ehIY1EqIvg7eNzeytujQ1p0EDSBK4p 5ecNbrvGSO66at32FozP3WkbTz+anoLk80TvFx5uU3pqxwoRtlI21JcpD6FjdwFpyaprbmZ3C NcBhEDYvGOtGZlehjX2TIySysbyisqzeZ5FY8mtRWK8QdtIvE1maHzHTB90oNM35KJZPWKRv9 Qi6oiyRr2qNcvlLu9LeYISNIgUmkdgNYazxSENRuUs0ANN/VgDBnrhR6irR/JJJEcmURqLLoZ KMp0ooj6e1UO1PSDhz4vjESVG49uWvAu2xe90ojGyC+wHI32JBuuzzBlYJKA388HcTxbHyPy9 udrEDxhWZoKZ9gdYgOepFqKjkik9ts52wMskWbJdVFCNt0kveFgVA7pWgiAktSPwhkrJxRocT DwPU+7tC04r3oNhVmuUXPEfDgt7FKxDqAV7YhiS8XCjybR+RUwlT1L5KRK9xecwahLlKo7HjI ij6gox0TXqzoLjFGHeplqVMkUMpkpgWz6SyhZl037HMptRSMSW9vl9ZKwgZuILWMQ0kcQmWqY +cP+vM690fEPxlvVlU7BIm0J7GmXIoZRkEqvDr6BVKmTy/U/1k= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> There can be additional means be used to reduce the probability >> of undesired side effects. > > Irrelevant, I got an other opinion here. > it doesn't fix a bug, Did I suggest to correct a coding style “bug”? > nor dramatic improvement. I agree that the change could be small only for this software module alone. I guess that we discuss not only change patterns for this one but also other affected modules here (besides a concrete example). The result summary might be more significant overall. >>> 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”? > > Impression doesn't matter. It seems then that you can not get the kind of information you might be looking for at the moment from me (alone). > The question is whether it's 100% correct or not in such a case. Would any other source code reviewers like to provide a corresponding acknowledgement for concrete changes? >> Are there any more software developers and code reviewers available >> who would like to point another programming mistake out for this Linux module? > > If you have find such, then it's fine, you can get your patches > reviewed and more assured. I hope that mailing list readers could offer something. > But in the current situation, no one else is interested in it, > and that's going to nowhere. Did this software module become “too old”? > The *really* trivial ones were applied. The rest are not. Can higher level transformation patterns become easier to accept by any other means? >> Do you need any more information to see and eventually accept the sense again? > > No. This kind of code refactoring has no more information. > It's a "trivial" change, after all. Would you like to distinguish the possible update steps better to avoid further confusion around “triviality”? >> Are you using a continuous integration system? > > Not really in my side. But there are others doing that. How much does the omission of such an useful development tool influence your concerns? Would you like to improve the software situation in any ways there? Regards, Markus