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

[Yury Norov <ynorov at caviumnetworks dot com>]

On Tue, Aug 09, 2016 at 11:17:59PM +0200, Arnd Bergmann wrote:
> On Tuesday, August 9, 2016 9:03:54 PM CEST Joseph Myers wrote:
> > On Tue, 9 Aug 2016, Arnd Bergmann wrote:
> > 
> > > We cannot define 'struct timespec' to be incompatible with the version
> > > used by the kernel, that would break all other interfaces passing a
> > > timespec.
> > > 
> > > While in theory the kernel could change the definition of its "compat"
> > > data types for 32-bit tasks on 64-bit kernels (as it does for x86/x32),
> > > we are not doing that for aarch64, in order to stay compatible with
> > > device drivers that already have working compat mode on 32-bit ARM.
> > 
> > So in that case, if the kernel's struct stat uses 64-bit timespec, it's 
> > inevitably different from the userspace timespec.  Which leaves me 
> > wondering what the advantages of a userspace layout that's almost but not 
> > quite the same as the kernel's layout (and so needs timespec fields 
> > rearranged on structs received from the kernel) are over not doing 
> > anything special about the timespec fields in the userspace struct 
> > definition (that is, no special padding / alignment) and instead using the 
> > existing machinery for converting struct stat to convert from the kernel 
> > structure to the userspace structure.
> 
> Right, that would be what I listed as approach a) in my mail with
> message id 1914420.rMinRNpl2s@wuerfel earlier today, i.e. the
> easiest way to solve the problem.
> 
> 	Arnd

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.

Yury.