From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit Date: Fri, 16 May 2014 16:11:35 -0700 Message-ID: <53769B27.2090407@zytor.com> References: <1399971456-3941-1-git-send-email-lftan@altera.com> <4706636.rTYoqSXXOR@wuerfel> <9236147.lyD24Zv5SZ@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from terminus.zytor.com ([198.137.202.10]:60797 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753935AbaEPXMV (ORCPT ); Fri, 16 May 2014 19:12:21 -0400 In-Reply-To: <9236147.lyD24Zv5SZ@wuerfel> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann , "Joseph S. Myers" Cc: Chung-Lin Tang , John Stultz , Geert Uytterhoeven , Christoph Hellwig , Thomas Gleixner , Ley Foon Tan , Linux-Arch , "linux-kernel@vger.kernel.org" , LeyFoon Tan On 05/15/2014 01:38 PM, Arnd Bergmann wrote: > > For practical purposes in the kernel, we may still want to use 64-bit > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible > with the native type on 64-bit kernels, thus complicating the syscall > emulation layer. > > I don't know why timespec on x32 uses 'long tv_nsec', it does seem > problematic. struct timespec is specified in POSIX as having type "long" for tv_nsec. This, as Linus pointed out, is totally braindamaged. x32 does not follow POSIX (Linus pretty much dictated that), and instead does the __kernel_suseconds_t to match the native kernel type. The proposal at some point was to try to push a snseconds_t into POSIX. -hpa