Re: [PATCH v4 2/3] 32-bit ABIs: support stat syscall family

[Arnd Bergmann <arnd at arndb dot de>]

On Wednesday, August 17, 2016 10:13:57 PM CEST Yury Norov wrote:
> Hi Arnd, Joseph,
> 
> Is my understanding correct that you suggest to use __xstat_conv(),
> like in sysdeps/unix/sysv/linux/fxstat.c? I was thinking on it. If
> aarch64/ilp32 was the single case, I'd choose it. But this (64-bit
> fields) is new standard, so any other who will add new port will meet
> this problems again, and will add similar hacks to kernel_stat.h and
> xstatconv.h as I (like defining __NR_fstat to __NR_fstat64). 
> 
> So I did choose new layout prior to existing conversion because:
>  - this is generic behavior and so generic solution is preferable.
>  - as it is generic, it should be effective, and useless copying of
>    kernel_stat fields to stat fields and extra stack consumption are
>    not welcome.
>  - 32-bit time_t is not for too long, and one day kernel and userspace
>    layouts of struct stat will become completely identical, so any
>    conversion will not be needed anymore.
>  - and therefore differences in time fields may be treated as special
>    case, and I can manipulate them special way.
> 
> After this discussion I realize that some of my assumptions may be
> wrong. But I still think that new layout is better choice than the
> runtime conversion of almost identical structures.
> 
> Anyway, I'm ready to rewrite it. Just give me clear understanding what
> we want.

Here is my (current) take on the situation:

The kernel interface for 'stat' on new 32-bit architectures is what
is defined in 'struct stat64' in include/uapi/asm-generic/stat.h.

This structure uses 32-bit time fields, whether we like it or not.
When we get a generic replacement for 'struct stat64' on 32-bit
architectures and the 'sys_stat64' implementation in the kernel,
that structure will use 64-bit time members, but have a different name
and will be available on all architectures (no arch specific
definitions for new structures), so don't worry about 64-bit
time_t here.

We've gone back and forth on the arm64+ilp32 definition of the
existing stat64 , because that one cannot easily use the same
generic structure. I originally thought that using the 64-bit
layout of 'struct stat' was a good idea for arm64, but now
I don't see much of an advantage either way (the existing arm32
'struct stat64' layout or the existing  arm64 'struct stat' layout).

Both of them are incompatible with the default layout for all
other new 32-bit architectures in user space, so pick one of the
two for the kernel interface, and convert it to the normal layout
in glibc using __xstat_conv():

- if you use the arm64 'struct stat' layout (as in the current
  kernel patches), you need a temporary buffer with the larger
  size and then copy over the time fields one by one
- if you instead use the arm32 'struct stat64' layout in the kernel,
  the size is the same, and the conversion is a one-line
  assignment of st_ino.

	Arnd