[U-Boot] [PATCH V2] arm: Use optimized memcpy and memset from linux

[Albert ARIBAUD <albert.aribaud@free.fr>]

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.