Linux Extended-stat system call

Linux Extended-stat system call

[David Howells]

Hi,

I'm in the throes of creating an extended-stat system call that:

 (1) Is available in exactly the same form across all arches.

 (2) Expands various fields, most notably timestamps and file size.

 (3) Allows Linux to return extra data to the user - such as the
     creation/birthtime of a file.

 (4) Provides spare space for future expansion without the need to add further
     stat syscalls.

 (5) Provides indicators of what information is actually retrieved (for
     instance, did we actually get given a UID and GID, or were these made
     up, ...).

 (6) Provides information about a file and the VFS's view of it (for instance,
     is the file kernel-API - such as in /proc, is it encrypted, ...).

The code I have currently can be found here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=xstat

It has been published on various kernel mailing lists for discussion.

One thing I would like to do is make it so that stat() can use it with minimal
effort.  Now, I appreciate that struct statx contains a lot more than can be
fitted into struct stat, so making it compatible might not be possible.
However, correctly arranging the fields in struct statx might simplify the job
of translating to glibc's idea of statx (ie. make it possible with just a
memcpy()).  Further, I note that there is some spare space in glibc's struct
stat - is that reserved for anything in particular (such as creation time)?

Any comments would be appreciated.

Thanks,
David

Re: Linux Extended-stat system call

[Florian Weimer]

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).

Thanks,
Florian

Re: Linux Extended-stat system call

[Arnd Bergmann]

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.

	Arnd

Re: Linux Extended-stat system call

[Florian Weimer]

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.

Florian

Re: Linux Extended-stat system call

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]