Re: [RFC v3 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64

[Alistair Francis <alistair23@gmail.com>]

On Thu, Jul 18, 2019 at 11:44 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Jul 18, 2019 at 7:36 PM Alistair Francis <alistair23@gmail.com> wrote:
> > On Thu, Jul 18, 2019 at 2:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thu, Jul 18, 2019 at 12:43 AM Alistair Francis <alistair23@gmail.com> wrote:
> > > >
> > > > Yes, if I use the generic ones for RV32 I see build failures as some
> > > > of the structs don't align (I can't remember which ones now). So this
> > > > is required to build.
> > >
> > > I think what it really means is that you have to fix up those build
> > > failures by changing the broken code. Using mismatched types to
> > > address build failures just replaces them with runtime failures but
> > > does not result in a working systems.
> >
> > Good point, I have fixed the other issue. This is what I have now,
> > which matches the generic typesizes:
>
> Ok, just to confirm, I'm looking at the difference between your
> version and sysdeps/unix/sysv/linux/generic/bits/typesizes.h:
>
> --- sysdeps/unix/sysv/linux/generic/bits/typesizes.h 2019-06-25
> 13:02:42.301241279 +0200
> +++ typesize.h +0200
> ...
>  #define __DEV_T_TYPE __UQUAD_TYPE
>  #define __UID_T_TYPE __U32_TYPE
>  #define __GID_T_TYPE __U32_TYPE
> -#define __INO_T_TYPE __ULONGWORD_TYPE
> +#define __INO_T_TYPE    __UQUAD_TYPE
>  #define __INO64_T_TYPE __UQUAD_TYPE
>  #define __MODE_T_TYPE __U32_TYPE
>  #define __NLINK_T_TYPE __U32_TYPE
> -#define __OFF_T_TYPE __SLONGWORD_TYPE
> +#define __OFF_T_TYPE    __SQUAD_TYPE
>  #define __OFF64_T_TYPE __SQUAD_TYPE
>  #define __PID_T_TYPE __S32_TYPE
> -#define __RLIM_T_TYPE __ULONGWORD_TYPE
> +#define __RLIM_T_TYPE      __UQUAD_TYPE
>  #define __RLIM64_T_TYPE __UQUAD_TYPE
> -#define __BLKCNT_T_TYPE __SLONGWORD_TYPE
> +#define __BLKCNT_T_TYPE    __SQUAD_TYPE
>  #define __BLKCNT64_T_TYPE __SQUAD_TYPE
> -#define __FSBLKCNT_T_TYPE __ULONGWORD_TYPE
> +#define __FSBLKCNT_T_TYPE  __UQUAD_TYPE
>  #define __FSBLKCNT64_T_TYPE __UQUAD_TYPE
> -#define __FSFILCNT_T_TYPE __ULONGWORD_TYPE
> +#define __FSFILCNT_T_TYPE  __UQUAD_TYPE
>  #define __FSFILCNT64_T_TYPE __UQUAD_TYPE
>  #define __FSWORD_T_TYPE __SWORD_TYPE
>  #define __ID_T_TYPE __U32_TYPE
>  #define __CLOCK_T_TYPE __SLONGWORD_TYPE
> -#define __TIME_T_TYPE __SLONGWORD_TYPE
> +#define __TIME_T_TYPE      __SQUAD_TYPE
>  #define __USECONDS_T_TYPE __U32_TYPE
> -#define __SUSECONDS_T_TYPE __SLONGWORD_TYPE
> +#define __SUSECONDS_T_TYPE __SQUAD_TYPE
>  #define __DADDR_T_TYPE __S32_TYPE
>  #define __KEY_T_TYPE __S32_TYPE
>  #define __CLOCKID_T_TYPE __S32_TYPE
> ...
>
> This all seems reasonable, but it's worth spelling out the decisions
> that went into it:
>
> -  All the !__USE_FILE_OFFSET64  types (__off_t, __ino_t, __rlim_t, ...) are
>   changed to match the 64-bit replacements. I would have preferred to
>   completely leave them out and always define __USE_FILE_OFFSET64,
>   but I don't think anyone else liked that idea, so that's ok.
>
> - __time_t is defined to 64 bit, but no __time64_t is added. This makes sense
>   as we don't have the time64 support for other 32-bit architectures yet, and
>   it will be easy to change when that happens.
>
> - __suseconds_t is 64-bit. This matches what we use the kerne ABI for the
>   few drivers that are relying on 'struct timeval' input arguments in
> ioctl, as well as
>   the adjtimex system call. It means that timeval has to be defined without the
>   padding, unlike timespec, which needs padding.

Great! I have added all of this into the commit message (with some changes)

Alistair

>
>       Arnd