On Mon, Jun 06, 2016 at 10:03:49PM +0300, Pinski, Andrew wrote: > You may also want to look into this thread. It just got started too. > > -----Original Message----- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Monday, June 6, 2016 12:03 PM > To: Pinski, Andrew <andrew.pin...@cavium.com> > Subject: Fwd: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new > 32-bit architectures? > > ---------- Forwarded message ---------- > From: Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> > Date: Mon, Jun 6, 2016 at 11:51 AM > Subject: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit > architectures? > To: libc-al...@sourceware.org > > > Hi, > > When discussing how to implement these types for the RISC-V architecture (32, > 64 and 128-bit flavours), it seems that there's a drive [1][2] to force new > arches to use the 64-bit versions of these types (so they would be the same > as __OFF64_T_TYPE and __INO64_T_TYPE), even for 32-bit arches. > > Does this look like a reasonable approach? > > > https://github.com/manuelafm/riscv-gnu-toolchain/commit/764f5ac958618c1ca8761845864164365282ffbd > > (also attached) >
Hi Manuel, It seems, we are working on the same issue. AARCH64/ilp32 ABI is going to work the way you described below. I found next types to be turned to 64-bit [https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1157969.html]: > So for AARCH64/ILP32 we turn next types to 64-bit in glibc: > #define __INO_T_TYPE __UQUAD_TYPE > #define __OFF_T_TYPE __SQUAD_TYPE > #define __BLKCNT_T_TYPE __SQUAD_TYPE > #define __FSBLKCNT_T_TYPE __UQUAD_TYPE > #define __FSFILCNT_T_TYPE __UQUAD_TYPE > > And define: > # define __INO_T_MATCHES_INO64_T 1 > # define __OFF_T_MATCHES_OFF64_T 1 > # define __BLKCNT_T_MATCHES_BLKCNT64_T 1 > # define __FSBLKCNT_T_MATCHES_FSBLKCNT64_T 1 > # define __FSFILCNT_T_MATCHES_FSFILCNT_T 1 > > If so, stat and statfs structures for ilp32 are turning the same as > for lp64. And so we'd handle related syscalls with native lp64 > handlers (wrapped, to zero top halves) in kernel. ^^^ The main goal ^^^ > > And we don't need stat64 for ilp32. > > Did I miss something? Is everything correct? > > https://github.com/norov/glibc/commits/ilp32-dev > https://github.com/norov/linux/commits/ilp32 > Under links below you can find my current progress on this work. Also notice how I redeclared struct timespec. #ifdef timespec_needs_pads # if __BYTE_ORDER == __LITTLE_ENDIAN struct timespec { __time_t tv_sec; /* Seconds. */ int sec_pad; __syscall_slong_t tv_nsec; /* Nanoseconds. */ int nsec_pad; }; # else struct timespec { int sec_pad; __time_t tv_sec; /* Seconds. */ int nsec_pad; __syscall_slong_t tv_nsec; /* Nanoseconds. */ }; # endif #else struct timespec { __time_t tv_sec; /* Seconds. */ __syscall_slong_t tv_nsec; /* Nanoseconds. */ }; #endif /* timespec_needs_pads */ I'm little worry about correctness of this approach. But if you define the whole new RISC-V arch, I think, new timeskpec is OK there. BTW, just curious, why RISK-V. I think it will work for CISC as well. And what '-V' means? Yury. > > [1] At least from people in the Linux kernel community. > > [2] A further suggestion was that all new arches should default to have > the same width for these types, 64 bits, and override __OFF_T_TYPE > and __INO_T_TYPE for all the existing architectures where they are > currently 32-bits. I don't know if this is desirable at this point. > > > Cheers. > -- > Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>