This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 06/17] y2038: Change sys_utimensat() to use __kernel_timespec
- From: Christoph Hellwig <hch at infradead dot org>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: tglx at linutronix dot de, y2038 at lists dot linaro dot org, hch at infradead dot org, linux-api at vger dot kernel dot org, linux-arch at vger dot kernel dot org, libc-alpha at sourceware dot org, albert dot aribaud at 3adev dot fr, netdev at vger dot kernel dot org, viro at zeniv dot linux dot org dot uk, peterz at infradead dot org, dvhart at infradead dot org, ebiederm at xmission dot com, linux at dominikbrodowski dot net
- Date: Tue, 17 Jul 2018 05:52:43 -0700
- Subject: Re: [PATCH v2 06/17] y2038: Change sys_utimensat() to use __kernel_timespec
- References: <20180716161103.16239-1-arnd@arndb.de> <20180716161103.16239-7-arnd@arndb.de>
On Mon, Jul 16, 2018 at 06:10:52PM +0200, Arnd Bergmann wrote:
> When 32-bit architectures get changed to support 64-bit time_t,
> utimensat() needs to use the new __kernel_timespec structure as its
> argument.
>
> The older utime(), utimes() and futimesat() system calls don't need a
> corresponding change as they are no longer used on C libraries that have
> 64-bit time support.
>
> As we do for the other syscalls that have timespec arguments, we reuse
> the 'compat' syscall entry points to implement the traditional four
> interfaces, and only leave the new utimensat() as a native handler,
> so that the same code gets used on both 32-bit and 64-bit kernels
> on each syscall.
I wonder about the direction here: wouldn't it be easier to just
leave th existing syscall names as-is and introduce a new utimesat64
which uses the new timespec? We can then drop the old legacy utimesat
for new architectures added after the cutover.