Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757838AbcJQRSu (ORCPT ); Mon, 17 Oct 2016 13:18:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:60163 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752666AbcJQRSk (ORCPT ); Mon, 17 Oct 2016 13:18:40 -0400 Subject: Re: MD-RAID: Use seq_putc() in three status functions? To: SF Markus Elfring , linux-raid@vger.kernel.org References: <566ABCD9.1060404@users.sourceforge.net> <92c52f1d-d151-cea6-e9ac-31378e6862d0@users.sourceforge.net> <1475771699.1914.10.camel@perches.com> <77fb6fdc-7480-8607-0af1-42f73c125b9d@users.sourceforge.net> <688764a4-072d-2faf-37ba-a222b190a5d9@suse.de> <59d71170-c48d-a084-c748-b6ab74a2bee4@users.sourceforge.net> <1e151094-e228-5307-ae2f-b376b31f5628@suse.de> <83e720c6-9037-a3c1-6e83-27505805f37f@users.sourceforge.net> <2cc42b2f-1f1a-e95c-91fa-54e1dd3b6d49@suse.de> <653e60ee-f862-8828-3e4f-498c7cc34bdc@users.sourceforge.net> <1476703920.2520.105.camel@petrovitsch.priv.at> <97f31b70-e3ff-f194-c753-54da1fe3e664@users.sourceforge.net> <57299b72-8e6b-0b92-4374-1b7a0907e810@suse.de> <05d0cade-7922-9d8a-a974-34b2cc9150fb@suse.de> Cc: Bernd Petrovitsch , Christoph Hellwig , Guoqing Jiang , Jens Axboe , Joe Perches , Mike Christie , Neil Brown , Shaohua Li , Tomasz Majchrzak , LKML , kernel-janitors@vger.kernel.org, kbuild-all@01.org, ltp@lists.linux.it From: Hannes Reinecke Message-ID: <665cd40a-4562-a015-78c6-12976c12b626@suse.de> Date: Mon, 17 Oct 2016 19:18:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1679 Lines: 45 On 10/17/2016 06:08 PM, SF Markus Elfring wrote: >>> * Would you really like to know under which circumstances data processing >>> will be faster for a single character instead of using a string pointer >>> and corresponding two characters? >>> >> It's not a problem of the interface, it's a problem of the resulting code >> (ie assembler output). > > How do you think about to discuss concrete generated code any further? > Sure. Show me the generated code and point out where the benefits are. >> We can discuss all we like, if the compiler decides to throw in >> an optimisation none of the arguments even apply. > > Would it make sense to clarify assembler output with optimisation switched off? > > Do you eventually care for code from non-optimising compilers? > No. This is the linux kernel. There is a very, _very_ limited benefit of trying to use a non-standard compiler. > >>> * Will it occasionally be useful to avoid the storage for another string literal? >>> >> Occasionally: yes. >> In this particular case: hardly. > > I am curious when such a software design aspect can become more relevant. > Would it be nice to get rid of three questionable string terminators (null bytes) > for example? > Again, all this does it trying to out-guess what the compiler might be doing during compilation. For which the easiest method is checking. So back to the original task for you: Show me in the generated output where the benefits are. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)