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

[Yury Norov <ynorov at caviumnetworks dot com>]

On Thu, Aug 25, 2016 at 05:34:23PM +0200, Arnd Bergmann wrote:
> 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

Ok. I'll do like this. I'd prefer 1st option, because 2nd implies
allocating big buffer on kernel side.

Yury.