From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752176AbcACSuf (ORCPT ); Sun, 3 Jan 2016 13:50:35 -0500 Received: from mout.web.de ([212.227.17.12]:54548 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751221AbcACSub (ORCPT ); Sun, 3 Jan 2016 13:50:31 -0500 Subject: Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() To: Greg Kroah-Hartman References: <566ABCD9.1060404@users.sourceforge.net> <56894D2D.1010801@users.sourceforge.net> <56895EE1.7080808@users.sourceforge.net> <20160103175816.GA21611@kroah.com> <56896591.2030208@users.sourceforge.net> <20160103182640.GA30692@kroah.com> Cc: Julia Lawall , devel@driverdev.osuosl.org, kernel-janitors@vger.kernel.org, LKML , Lior Dotan , Christopher Harrer From: SF Markus Elfring X-Enigmail-Draft-Status: N1110 Message-ID: <56896D6A.6020309@users.sourceforge.net> Date: Sun, 3 Jan 2016 19:50:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160103182640.GA30692@kroah.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:L3YTj/3reDuyAcEac86XaAJLFmgkqPieA6XVLEHispCzK/TvTt1 JOyizvtQJ1bHlaQfHdgUZyE9BPxE+Knv0ne/OjSPe7LcE3/Aawm30Vo0gxVcaacG34VhYrv ajzGFQCNzPCb9xJjWU6yLi8WuqF6V2leE2g0Xj8AZww0rtjQg3COovNQf/q1gy+k1QIqtNv aJtLDB4mB5bLfjLddX4bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZxzMLodFxbU=:dxHUtVam89DjhJUO22A3QD Y0LC2Tylcg5RqvxvSEsJn7Iuxm/qfjrS8E1CqYwg6BgBZX1qVS13anm0+nels7q+GsnQA/ds2 8ohZhsn1n2GDmFMb5KvHFDxcEoO3KPRk7rJTeg4EF9EmBvUM0lCMfgdrRDlqK9EpFNzGMjv1c e44V1Tb9uAsM04xtJNvOOLaB7wImCgRuEuoB/PlM4yRT7hb/j7grhtL8VYZm/XdpWireMSLZ6 ScaY9lw/vZl1p0KrLDBjLo4Qus6honCsphYg5rphMaymn7nszUXmAQcb4A1B7MD20PUfh9hMu 93i7D0asnI/0sFR5zj/49uxmZcj0DQ/l51+DVqDZMkji+NRQXWZOvpK5tYwHJ438Pmq9el1Ay D8yWzxdZ/pIVI5Zjb6ln2c3CGwZSGUMhduoDXiVwD0GoIw2Zf+2P/ewlWepOIN+v8ZHnhjdU5 9B8ieGuipe/HLrzm0abz+tHR490FG/+oYt+dFJvTdqaMNbKhbFaTuW0IMwqMQ2prA7LOgBVLS kc25Q72w24blh61C5wltA0V7rjwjXd9wqIRjg4TNhOmcMOxLw7UVMmA5x+layfAtWWQePC5gT O+7HL1USWDy2ISq4/iIyQp3CfIdEbTloWZ7e0kxdBLL17M2fpuBpYjxfisEy7wmxcjYFLGNki lQs+kZyguSOEfjOrZQanrTVjkOjXXBKJfjUW0PffrvyNbrFWvLh5yxWi3Nfzmpq0k0XUqXN+4 9SXAJKv+mbm4POf7roONemDgx9YEIzC0E3VHBHqp4qlMQ2Ipy+SR5EstCnfGOVJcObwPt9BoB x/MLDlK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> I am a bit surprised that you do not like such source code fine-tuning. > > It's moving stuff around for no real reason, why would I like it? Can such fine-tuning result in positive effects for the run-time behaviour? > Reading and reviewing and applying this type of stuff takes away from > the time I have to spend reviewing and applying actual code fixes from > other developers who are doing real and useful work. I am aware that a lot of open issues are competing for your precious software development attention. > Remember maintainer's time is our most limited resource right now. That is mostly usual. > You are abusing that by wasting their time for no valid reason. I find a couple of my update suggestions still valid. I agree that the importance of proposed changes is varying. >> Will related software improvements get another chance later (eventually together >> with other changes)? > > Define "improvements". Did you fix an obvious bug? Maybe. - It depends on the error classes you are interested in at the moment. > Did you speed up the code in a measurable way? My suggestions can result in measurable differences. > Did you make the code easier to understand somehow? > For this patch you did none of these things. Thanks for your view on my approach. Will it become acceptable to reduce the scope for any more variable definitions in further function implementations? > Code in staging needs to be moved out of staging, and this patch does > nothing toward achieving that goal and it wastes people's time reviewing > it to see if it is correct or not. I am curious on the ways the discussed software can evolve further. Regards, Markus From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Sun, 03 Jan 2016 18:50:18 +0000 Subject: Re: [PATCH] staging-slicoss: Replace variable initialisations by assignments in slic_if_init() Message-Id: <56896D6A.6020309@users.sourceforge.net> List-Id: References: <566ABCD9.1060404@users.sourceforge.net> <56894D2D.1010801@users.sourceforge.net> <56895EE1.7080808@users.sourceforge.net> <20160103175816.GA21611@kroah.com> <56896591.2030208@users.sourceforge.net> <20160103182640.GA30692@kroah.com> In-Reply-To: <20160103182640.GA30692@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Kroah-Hartman Cc: Julia Lawall , devel@driverdev.osuosl.org, kernel-janitors@vger.kernel.org, LKML , Lior Dotan , Christopher Harrer >> I am a bit surprised that you do not like such source code fine-tuning. > > It's moving stuff around for no real reason, why would I like it? Can such fine-tuning result in positive effects for the run-time behaviour? > Reading and reviewing and applying this type of stuff takes away from > the time I have to spend reviewing and applying actual code fixes from > other developers who are doing real and useful work. I am aware that a lot of open issues are competing for your precious software development attention. > Remember maintainer's time is our most limited resource right now. That is mostly usual. > You are abusing that by wasting their time for no valid reason. I find a couple of my update suggestions still valid. I agree that the importance of proposed changes is varying. >> Will related software improvements get another chance later (eventually together >> with other changes)? > > Define "improvements". Did you fix an obvious bug? Maybe. - It depends on the error classes you are interested in at the moment. > Did you speed up the code in a measurable way? My suggestions can result in measurable differences. > Did you make the code easier to understand somehow? > For this patch you did none of these things. Thanks for your view on my approach. Will it become acceptable to reduce the scope for any more variable definitions in further function implementations? > Code in staging needs to be moved out of staging, and this patch does > nothing toward achieving that goal and it wastes people's time reviewing > it to see if it is correct or not. I am curious on the ways the discussed software can evolve further. Regards, Markus