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

[Arnd Bergmann <arnd@arndb.de>]

On Tuesday 30 August 2016, Yury Norov wrote:
> On Tue, Aug 30, 2016 at 05:15:44PM +0200, Arnd Bergmann wrote:
> > On Tuesday 30 August 2016, Yury Norov wrote:
> > > On Mon, Aug 29, 2016 at 10:34:38PM +0200, Arnd Bergmann wrote:
> > 
> > + new version with conversion of st_ino field only, a different new hack
> >   but simpler.
> > 
> > >  - initial version. Effective, simple, free of hacks but (because of)
> > >    non-generic.
> > 
> > I can't find that version now, can you post a copy of that original
> > patch or a link to an archived discussion?
> > 
> 
> It seems I never published it. It was based on arm32 syscall handlers,
> and in kernel list it was decided to use aarch64 wrappers, so I
> dropped it. Briefly, there was custom struct stat that was identical
> to struct stat64, and identical to kernel one. The rest is like in
> previous version except there were no code that converts timespecs.
> 
> > The layout we want is exactly what we have for stat64
> > sysdeps/unix/sysv/linux/bits/stat.h (not
> > sysdeps/unix/sysv/linux/generic/bits/stat.h), right?
> > 
> > 	Arnd
> 
> This is the implementation of fxstat() and lxstat() syscalls that use standard
> struct stat layout, and convert kernel_stat to user struct stat with
> __xstat{,64}_conv(). Here's used standard mechanism, but I had to move all
> syscalls under platform directory. Se the body of the patch for details.
> 
> I see no reason to continue this work as it's both ineffective and non-generic.
> Tomorrow I'll try the idea of Arnd - roll back to arm32 handlers in kernel, and
> try arm32 wrappers in glibc, or custom wrappers to avoid useless copying. I
> think there will be as much platform code, as in this version.

Ok, sounds good.

> Notice that it was already discussed in linux mail list, and aarch64 syscalls
> were called preferable because arm32 versions are broken (st_ino field), and
> other reasons.

I'm sure I was agreeing to that at the time, but after the long discussions
we have had since, working around the st_ino problem seems much simpler than
working around the incompatible timestamps.

	Arnd