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

[Arnd Bergmann <arnd@arndb.de>]

On Thu, Jul 18, 2019 at 12:43 AM Alistair Francis <alistair23@gmail.com> wrote:
> On Wed, Jul 17, 2019 at 1:27 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wed, Jul 17, 2019 at 2:11 AM Alistair Francis
> > <alistair.francis@wdc.com> wrote:
> >
> > > +#define __DEV_T_TYPE    __UQUAD_TYPE
> > > +#define __UID_T_TYPE    __U32_TYPE
> > > +#define __GID_T_TYPE    __U32_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    __SQUAD_TYPE
> > > +#define __OFF64_T_TYPE     __SQUAD_TYPE
> > > +#define __PID_T_TYPE    __S32_TYPE
> > > +#define __RLIM_T_TYPE      __UQUAD_TYPE
> > > +#define __RLIM64_T_TYPE    __UQUAD_TYPE
> > > +#define __BLKCNT_T_TYPE    __SQUAD_TYPE
> > > +#define __BLKCNT64_T_TYPE  __SQUAD_TYPE
> > > +#define __FSBLKCNT_T_TYPE  __UQUAD_TYPE
> > > +#define __FSBLKCNT64_T_TYPE   __UQUAD_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      __SQUAD_TYPE
> > > +#define __USECONDS_T_TYPE  __U32_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
> > > +#define __TIMER_T_TYPE     void *
> > > +#define __BLKSIZE_T_TYPE   __S32_TYPE
> > > +#define __FSID_T_TYPE      struct { int __val[2]; }
> > > +#define __SSIZE_T_TYPE     __SWORD_TYPE
> > > +#define __SYSCALL_SLONG_TYPE __SQUAD_TYPE
> > > +#define __SYSCALL_ULONG_TYPE __UQUAD_TYPE
> > > +#define __CPU_MASK_TYPE    __UQUAD_TYPE
> >
> > I see you fixed __CLOCK_T_TYPE, but you still have a number
> > of types that differ from the kernel ABI for no apparent reason.
> >
> > Is this intentional?
>
> 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.

    Arnd