From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756694AbdCUJEz (ORCPT ); Tue, 21 Mar 2017 05:04:55 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:41939 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755576AbdCUJEw (ORCPT ); Tue, 21 Mar 2017 05:04:52 -0400 Date: Tue, 21 Mar 2017 10:04:09 +0100 (CET) From: Thomas Gleixner To: Arnd Bergmann cc: Deepa Dinamani , Linux Kernel Mailing List , John Stultz , y2038 Mailman List Subject: Re: [RESEND PATCH 2/7] time: Change posix clocks ops interfaces to use timespec64 In-Reply-To: Message-ID: References: <1489900666-32268-1-git-send-email-deepa.kernel@gmail.com> <1489900666-32268-3-git-send-email-deepa.kernel@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 Mar 2017, Arnd Bergmann wrote: > On Mon, Mar 20, 2017 at 9:40 PM, Thomas Gleixner wrote: > > On Mon, 20 Mar 2017, Deepa Dinamani wrote: > >> >> -static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp) > >> >> +static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp) > >> > > >> > That's a pretty pointless exercise. getres() returns the resolution of the > >> > clock which obviously can never be affected by Y2038. > >> > >> True, tv_sec does not need to be more than 32 bits here. > >> We plan to limit the use of struct timespec to existing user interfaces only. > > > > This is an existing user space interface and there is no need to change it > > at all. > > I think we should change it in the kernel, otherwise every libc implementation > has to include a copy of this, to convert between the user space 16-byte > timespec and the 8-byte kernel timespec. If we do it in the kernel, we only > need one copy and the interface is consistent between 32-bit and 64-bit > user space. Fair enough. Please add a comment which explains why this uses a timespec64 as it is not obvious - as demonstrated :) Thanks, tglx