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


Groups > linux.kernel > #1400862

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

From Arnd Bergmann <arnd@arndb.de>
Newsgroups linux.kernel
Subject Re: [PATCH 1/6] statx: Add a system call to make enhanced file info available
Date 2016-05-13 17:30 +0200
Message-ID <ryncl-6eB-3@gated-at.bofh.it> (permalink)
References <rx9XQ-5Zf-13@gated-at.bofh.it> <rxbdg-76W-25@gated-at.bofh.it> <rxUWL-2AG-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

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

csiph-web