[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 3/3] x86/string: Clean up x86/string.h

On 15/05/17 11:19, Jan Beulich wrote:
>  >>> On 15.05.17 at 12:08, <JBeulich@xxxxxxxx> wrote:
>>>>> On 12.05.17 at 19:35, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/include/asm-x86/string.h
>>> +++ b/xen/include/asm-x86/string.h
>>> @@ -2,13 +2,23 @@
>>>  #define __X86_STRING_H__
>>>  #define __HAVE_ARCH_MEMCPY
>>> -#define memcpy(t,f,n) (__builtin_memcpy((t),(f),(n)))
>>> +void *memcpy(void *dest, const void *src, size_t n);
>>> +#define memcpy(d, s, n) __builtin_memcpy(d, s, n)
>>> -/* Some versions of gcc don't have this builtin. It's non-critical anyway. 
>> */
>>>  #define __HAVE_ARCH_MEMMOVE
>>> -extern void *memmove(void *dest, const void *src, size_t n);
>>> +void *memmove(void *dest, const void *src, size_t n);
>>> +#define memmove(d, s, n) __builtin_memmove(d, s, n)
>>>  #define __HAVE_ARCH_MEMSET
>>> -#define memset(s,c,n) (__builtin_memset((s),(c),(n)))
>>> +void *memset(void *dest, int c, size_t n);
>>> +#define memset(s, c, n) __builtin_memset(s, c, n)
>> Now that xen/string.h has the exact same declarations and
>> definitions already, why don't you simply delete the overrides
>> from here?
> Hmm, wait - I guess you need to keep them because of the custom
> implementation. That's awkward, there shouldn't be a need to have
> redundant declarations just because there are custom
> implementations. How about making __HAVE_ARCH_* serve both
> purposes, by allowing it to have different values (besides being
> defined or undefined)?

I don't understand how you would intend this new __HAVE_ARCH_* to work.

ARM uses the current behaviour to implement memset() as a local macro.

Given that these files aren't likely to change much at all, I'd
recommend keeping the same behaviour as Linux.  It is only 3 lines after


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.