Re: FW: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?

Re: FW: [RFC] Forcing 64-bits __OFF_T_TYPE and __INO_T_TYPE for new 32-bit architectures?

[Yury Norov]

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:pinskia@gmail.com] 
> Sent: Monday, June 6, 2016 12:03 PM
> To: Pinski, Andrew <Andrew.Pinski@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.montezelo@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-alpha@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.montezelo@gmail.com>