Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1400862 > unrolled thread

Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available Arnd Bergmann <arnd@arndb.de> - 2016-05-13 17:30 +0200
    Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells <dhowells@redhat.com> - 2016-05-18 13:00 +0200
    Re: [PATCH 1/6] statx: Add a system call to make enhanced file info  available Christoph Hellwig <hch@infradead.org> - 2016-05-23 10:30 +0200
      Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available David Howells <dhowells@redhat.com> - 2016-05-23 11:40 +0200

#1400862 — Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Thursday 12 May 2016 02:11:41 Christoph Hellwig wrote:
> On Tue, May 10, 2016 at 09:25:55AM +0100, David Howells wrote:
> > Because it's not necessarily a perfectly working version of it.  See the Y2037
> > problem for example.
> > 
> > I was assuming that C libraries might want to update the struct stat and the
> > stat call() to provide fields that aren't currently there in Linux but are in
> > other OS's.  We could even dispense with older stat syscalls on new arches.
> 
> Please stop this whole let's get rid of old syscalls on new
> architectures stuff.  This just means we have to do the translation
> multiple, and the one in userspace is more costly as we it needs to be
> in every copy of the library.  And times where we had a single libc
> instance (nevermind implementation) are long over if we ever actually
> had them.

I'm trying to understand what that means for the 64-bit time_t syscalls.

The patch series I did last year had a replacement 'sys_newfstatat()'
syscall but IIRC no other stat variant, the idea being that we would
only need to provide this one to the libc and have user space emulate
the stat/fstat/lstat/fstatat variants based on that.
With the statx introduction, I was hoping to no longer have to add
that syscall but instead have libc do everything on top of sys_statx().

Do you think that is reasonable, given that we won't be allowed to
call any of the existing stat() variants for a y2038-safe libc build[1],
or should we plan to keep needing replacement fstatat (and possibly
stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support
is merged into the kernel.

	Arnd

[1] the glibc developers plan to allow compatibility for 32-bit time_t
    and 64-bit time_t in the same binary, but any user space code built
    with 64-bit time_t must never call into kernel interfaces that use
    a 32-bit time_t.

[toc] | [next] | [standalone]

#1402886

Arnd Bergmann <arnd@arndb.de> wrote:

> I'm trying to understand what that means for the 64-bit time_t syscalls.
> 
> The patch series I did last year had a replacement 'sys_newfstatat()'
> syscall but IIRC no other stat variant, the idea being that we would
> only need to provide this one to the libc and have user space emulate
> the stat/fstat/lstat/fstatat variants based on that.
> With the statx introduction, I was hoping to no longer have to add
> that syscall but instead have libc do everything on top of sys_statx().
> 
> Do you think that is reasonable, given that we won't be allowed to
> call any of the existing stat() variants for a y2038-safe libc build[1],
> or should we plan to keep needing replacement fstatat (and possibly
> stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support
> is merged into the kernel.

Christoph?

[toc] | [prev] | [next] | [standalone]

#1405163 — Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available

On Fri, May 13, 2016 at 05:28:11PM +0200, Arnd Bergmann wrote:
> I'm trying to understand what that means for the 64-bit time_t syscalls.
> 
> The patch series I did last year had a replacement 'sys_newfstatat()'
> syscall but IIRC no other stat variant, the idea being that we would
> only need to provide this one to the libc and have user space emulate
> the stat/fstat/lstat/fstatat variants based on that.
> With the statx introduction, I was hoping to no longer have to add
> that syscall but instead have libc do everything on top of sys_statx().
> 
> Do you think that is reasonable, given that we won't be allowed to
> call any of the existing stat() variants for a y2038-safe libc build[1],
> or should we plan to keep needing replacement fstatat (and possibly
> stat/lstat/fstat) syscalls with 64-bit time_t even after statx() support
> is merged into the kernel.

Honestly I think this really matters on the amount of 'emulation' we
need - if it's just adding a new flag that can be trivially generated
in the syscall stub in userland that's probably fine, but if we have
actually differing semantics (like the stat weak attributes) I'd rather
have a properly documented syscall.  If we otherwise need to rewrite
whole structures I'd much rather do that in kernel space.

And to get back to stat: if would be really useful to coordinate the
new one with glibc so that we don't end up with two different stat
structures again like we do for a lot of platforms at the moment.

[toc] | [prev] | [next] | [standalone]

#1405194

Christoph Hellwig <hch@infradead.org> wrote:

> Honestly I think this really matters on the amount of 'emulation' we
> need - if it's just adding a new flag that can be trivially generated
> in the syscall stub in userland that's probably fine, but if we have
> actually differing semantics (like the stat weak attributes) I'd rather
> have a properly documented syscall.  If we otherwise need to rewrite
> whole structures I'd much rather do that in kernel space.

I very much agree.

> And to get back to stat: if would be really useful to coordinate the
> new one with glibc so that we don't end up with two different stat
> structures again like we do for a lot of platforms at the moment.

I've tried reaching out to them and others, but no one responded.

David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web