From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 27 Jan 2011 19:39:09 +0100 Subject: [U-Boot] [PATCH V2] arm: Use optimized memcpy and memset from linux In-Reply-To: <20110126130720.D0DA5CD1385@gemini.denx.de> References: <1295884607-9044-1-git-send-email-weisserm@arcor.de> <1296038757-11800-1-git-send-email-weisserm@arcor.de> <4D400E99.9000800@free.fr> <4D4018AD.7090001@arcor.de> <20110126130720.D0DA5CD1385@gemini.denx.de> Message-ID: <4D41BBCD.2070006@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, Le 26/01/2011 14:07, Wolfgang Denk a ?crit : > Dear =?ISO-8859-15?Q?Matthias_Wei=DFer?=, > > In message<4D4018AD.7090001@arcor.de> you wrote: >> >>> IIRC, the '---' line separates patch commit message (above) from >>> freeform comments and history (below). Here, at least the version >>> history should move below the '---' line. >> >> Wolfgang asked me that I add the numbers to the commit message. For the >> changelog I will investigate the git commands on how to do that best >> without manually editing the patch file before git send-email them. > > Indeed I find that these numbers are information that should go into > the commit message so this data is available to users who have to > decide whether they want to trade the increased speed for the > increased memory footprint. Can't we have thses numbers in a more compact form then? That makes a really big commit message. >>>> +- CONFIG_USE_ARCH_MEMCPY >>>> + CONFIG_USE_ARCH_MEMSET >>>> + If these options are used a optimized version of memcpy/memset will >>>> + be used if available. These functions may be faster under some >>>> + conditions but may increase the binary size. >>>> + >>> >>> The name of the options is not self-explaining to me. If the difference >>> is "generic vs arch-optimal", then maybe CONFIG_USE_ARCH_OPTIMAL_MEMxxx >>> would be a better name? >> >> Wolfgang didn't object on these names. If we use the OPTIMAL form it is >> still not clear what optimal mean. There may be a size optimized version >> and a speed optimized version. So we would need >> CONFIG_USE_ARCH_SPEED_OPTIMAL_MEMxxx which I personally dislike a lot as >> it is quite long. I also think that if there is an architecture specific >> function that it should be clear that this is optimal in some way. > > Well, "optimal" is not a good idea as I am pretty sure that some > clever person will still be able to spare some cycles here and there, > so his code would be even "more optimal" ;-) Granted. > I think the names CONFIG_USE_ARCH_MEMCPY etc. are actually pretty > good, because they are in line with the standard names > __HAVE_ARCH_MEMCPY etc. that are used in a lot of libraries. All right. > Best regards, > > Wolfgang Denk Amicalement, -- Albert.