Linux Extended-stat system call

[Mike Frysinger]

On 24 Jun 2016 17:37, Florian Weimer wrote:
> On 06/22/2016 06:03 PM, Arnd Bergmann wrote:
> > On Wednesday, June 22, 2016 5:03:43 PM CEST Florian Weimer wrote:
> >> On 06/22/2016 04:08 PM, David Howells wrote:
> >>> One thing I would like to do is make it so that stat() can use it with minimal
> >>> effort.
> >>
> >> Why is this an important goal?
> >>
> >> Existing architectures will keep using the old system call for the
> >> legacy stat interfaces.  New architectures can use the new system call,
> >> but will probably have a different definition of struct stat (which
> >> might well be guided by our experience with the extended stat interface).
> >
> > For the y2038 work, we have to replace the stat system call on all 32-bit
> > architectures (and mips64, which uses 32-bit st_mtime). We can do this
> > by adding just a new version of the fstatat() syscall to the kernel that
> > matches the ABI of the 64-bit architectures, or by mapping everything
> > onto the new xstat.
> >
> > Adding just one new syscall entry point instead of two simplifies the
> > kernel implementation quite a bit, but if there are good reasons for
> > still providing a new fstatat version, we could do that too.
> 
> Thanks for providing the background.
> 
> If we can get all the data with a single system call, I don't think it 
> matters much were we do the translation.  A single new system call is 
> less work for strace, so I assume that's the way to go.

i think it would even be a code cleanup on our side.  at some point glibc
will require a kernel where all arches have the new stat syscall, so we'd
be able to (hopefully) cleanse all the ugly xstat/xstat64 code into just
one code path.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160624/85532e30/attachment.sig>