This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Patch] aarch64: Thunderx specific memcpy and memmove
- From: Steve Ellcey <sellcey at caviumnetworks dot com>
- To: Wainer dos Santos Moschetta <wainersm at linux dot vnet dot ibm dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Cc: Siddhesh Poyarekar <siddhesh at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Thu, 06 Apr 2017 13:48:15 -0700
- Subject: Re: [Patch] aarch64: Thunderx specific memcpy and memmove
- Authentication-results: sourceware.org; auth=none
- Authentication-results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none;linux.vnet.ibm.com; dmarc=none action=none header.from=caviumnetworks.com;
- References: <1490397926.19074.73.camel@caviumnetworks.com> <b10d9388-3dbb-1505-bac9-92a9558a124c@linux.vnet.ibm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Sat, 2017-04-01 at 21:01 -0300, Wainer dos Santos Moschetta wrote:
> In sysdeps/aarch64/multiarch/memcpy_generic.S, it has:
> +#include "../memcpy.S"
>
> Is it ok to use relative path here? or rather it's recommended use of
> the full path since sysdeps?
I think its OK. I don't see any preference listed in the Coding Style
page of the glibc wiki for one way or the other. I see other includes
of relative paths, the most common one is '#include "../test-
skeleton.c"' but I also see other examples:
sysdeps/sparc/sparc64/multiarch/rtld-memset.c:#include "../rtld-memset.c"
sysdeps/sparc/sparc64/multiarch/rtld-memcpy.c:#include "../rtld-memcpy.c"
sysdeps/wordsize-64/ftw.c:#include "../../io/ftw.c"
sysdeps/wordsize-64/fts.c:#include "../../io/fts.c"
sysdeps/unix/sysv/linux/sparc/sparc64/xstat.c:#include "../../i386/xstat.c"
sysdeps/unix/sysv/linux/sparc/sparc64/fxstat.c:#include "../../i386/fxstat.c"
sysdeps/unix/sysv/linux/sparc/sparc64/fxstatat.c:#include "../../i386/fxstatat.c"
sysdeps/unix/sysv/linux/sparc/sparc64/lxstat.c:#include "../../i386/lxstat.c"
sysdeps/unix/sysv/linux/aarch64/readelflib.c:#include "../arm/readelflib.c"
sysdeps/unix/sysv/linux/wordsize-64/statvfs.c:#include "../statvfs.c"
sysdeps/unix/sysv/linux/wordsize-64/getdirentries.c:#include "../getdirentries.c"
sysdeps/unix/sysv/linux/wordsize-64/fstatvfs.c:#include "../fstatvfs.c"
sysdeps/unix/sysv/linux/wordsize-64/aio_write.c:#include "../../../../pthread/aio_write.c"
sysdeps/unix/sysv/linux/wordsize-64/openat.c:#include "../openat.c"
That seems more common than using:
sysdeps/unix/sysv/linux/s390/s390-32/updwtmp.c:#include "sysdeps/gnu/updwtmp.c"
sysdeps/unix/sysv/linux/s390/s390-32/getutmp.c:#include "sysdeps/gnu/getutmp.c"
sysdeps/x86_64/fpu/e_sqrtl.c:#include "sysdeps/i386/fpu/e_sqrtl.c"
sysdeps/x86_64/fpu/e_atan2l.c:#include "sysdeps/i386/fpu/e_atan2l.c"
sysdeps/x86_64/fpu/s_atanl.c:#include "sysdeps/i386/fpu/s_atanl.c"
sysdeps/x86_64/fpu/e_acosl.c:#include "sysdeps/i386/fpu/e_acosl.c"
Steve Ellcey