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

  2016-06-06 19:51 Manuel A. Fernandez Montecelo:
>
>Does this look like a reasonable approach?
>
> https://github.com/manuelafm/riscv-gnu-toolchain/commit/764f5ac958618c1ca8761845864164365282ffbd
>
> (also attached)

Sorry for the double posting.  Attaching for real now.
  

I would certainly support having off_t and ino_t always be 64-bit on
new architectures, even if they only support 32-bit pointers.  I am
not qualified to assess whether this patch is the right way to go
about it.

Shouldn't blkcnt_t, fsblkcnt_t, and fsfilcnt_t also get this
treatment?  (And anything else affected by -D_FILE_OFFSET_BITS=64 that
I missed.) And, while we're at it, time_t?

zw
  

On 06/06/2016 12:18 PM, Zack Weinberg wrote:
> And, while we're at it, time_t?

+1 on time_t. The year 2038 is not that far off. The others should be 
64-bit too.
  

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.

> (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).
  

On Monday, June 6, 2016 12:42:47 PM CEST Paul Eggert wrote:
> On 06/06/2016 12:18 PM, Zack Weinberg wrote:
> > And, while we're at it, time_t?
> 
> +1 on time_t. The year 2038 is not that far off. The others should be 
> 64-bit too.

I'm still working (not very actively at the moment) on the kernel
patches for time_t, right now the kernel only has 64-bit off_t, ino_t,
blkcnt_t, fsblkcnt_t and fsfilcnt_t for all 32-bit architectures,
and glibc emulates the 32-bit types on top of that, while the kernel
has 'long' for time_t basically everywhere.

	Arnd
  

On Mon, Jun 6, 2016 at 4:03 PM, Joseph Myers <joseph@codesourcery.com> wrote
> On Mon, 6 Jun 2016, Zack Weinberg wrote:
>> (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).

IMNSHO it's POSIX (and C also now, unfortunately) that should change
in that case; there should always have been an nsec_t.

zw
  

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.
  

On Monday, June 6, 2016 9:56:35 PM CEST Manuel A. Fernandez Montecelo wrote:
> 
> 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.
> 

Right, this is the plan for the kernel. I haven't made much progress here
since last year, but we definitely want to do this the same way for all
32-bit architectures, to avoid having more special cases in the kernel.

This means that for every syscall and ioctl command that passes a 32-bit
__kernel_time_t today, we will add a replacement with a 64-bit
__kernel_time64_t. Only after that is in place, we can have new
architectures that leave out the old interfaces based on __kernel_time_t,
similar to how how we no longer use __kernel_off_t today.

	Arnd