On Tue, Jun 21, 2016 at 10:35:27AM +0000, Joseph Myers wrote: > On Tue, 21 Jun 2016, Yury Norov wrote: > > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate64.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/llseek.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/lseek.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/mmap.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise64.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread64.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite64.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/readahead.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate.c > > create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate64.c > > I don't like how you need so many ilp32 files. > > Presumably this is a new convention to be followed for all future ilp32 > ABIs on 64-bit architectures. Meaning that you should have some sysdeps > macros to say whether this convention is in use and then make either the > sysdeps/unix/sysv/linux files, or the .../generic files, or a new > architecture-independent sysdeps directory, implement that convention. > > Note also how Adhemerval recently unified pread / pwrite implementations. > Adding new files for those functions goes against that unification. > > -- > Joseph S. Myers > jos...@codesourcery.com
Hi Joseph, There's RISC-V convention that implements very similar approach to aarch64/ilp32. https://github.com/manuelafm/riscv-gnu-toolchain/commits/master But as I understand, there is much work there to be done before upstreaming. So for now I think it's simpler to have this ABI in sysdeps, and be in touch with RISC-V team to have aarch64/ilp32 compatible to RISC-V. After RISC-V merge, we can switch aarch64/ilp32 to it and drop unneeded sysdeps. If you mean something different, could you explain it in details, or suggest an action plan for such rework. Yury.