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

["Manuel A. Fernandez Montecelo" <manuel dot montezelo at gmail dot com>]

2016-06-06 21:03 Joseph Myers:
> On Mon, 6 Jun 2016, Zack Weinberg wrote:
>
> > Shouldn't blkcnt_t, fsblkcnt_t, and fsfilcnt_t also get this
> > treatment?
>
> Yes, it would be desirable for struct {stat,statfs,statvfs} to match so
> that relevant functions can be aliases.  More *MATCHES* macros and
> corresponding implementation would be needed to cause the functions to be
> aliases, since much such aliasing is implemented through wordsize-64
> sysdeps directories at present.

Yep, good suggestion, thanks.

Should all of these changes be done for the RISC-V architecture in a
similar way as I did for off_t and ino_t?  Or is it better to do
something more generic, covering more arches?  (E.g. the example from my
initial message, setting 64-bit as default, then override for existing
arches where the values are 32-bit based).


> > (And anything else affected by -D_FILE_OFFSET_BITS=64 that
> > I missed.) And, while we're at it, time_t?
>
> For time_t, again, make sure to avoid the x32 mistake with a
> non-POSIX-conforming type for nanoseconds (you can have endian-appropriate
> explicit padding if you want to match a 64-bit ABI, but tv_nsec should
> have type "long" and the kernel needs to ignore the padding on input).

As Arnd said, it seems that Linux support is still not fully ready.

Also, it is my understanding that this change will be pushed to cover
existing 32-bit arches like x86 and arm-32 that will need this in the
near future (similar to -D_FILE_OFFSET_BITS=64, I suppose).  It is
probably better if support for RISC-V is added when there's a clear
picture on how to proceed.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>