From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751957AbaFBWam (ORCPT ); Mon, 2 Jun 2014 18:30:42 -0400 Received: from imap.thunk.org ([74.207.234.97]:46579 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbaFBWak (ORCPT ); Mon, 2 Jun 2014 18:30:40 -0400 Date: Mon, 2 Jun 2014 18:29:54 -0400 From: "Theodore Ts'o" To: "H. Peter Anvin" Cc: Chuck Lever , Arnd Bergmann , Nicolas Pitre , Dave Chinner , LKML Kernel , linux-arch@vger.kernel.org, joseph@codesourcery.com, john.stultz@linaro.org, Christoph Hellwig , tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com, linux-fsdevel , xfs@oss.sgi.com, Linux NFS Mailing List Subject: Re: [RFC 11/32] xfs: convert to struct inode_time Message-ID: <20140602222954.GA29690@thunk.org> Mail-Followup-To: Theodore Ts'o , "H. Peter Anvin" , Chuck Lever , Arnd Bergmann , Nicolas Pitre , Dave Chinner , LKML Kernel , linux-arch@vger.kernel.org, joseph@codesourcery.com, john.stultz@linaro.org, Christoph Hellwig , tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com, linux-fsdevel , xfs@oss.sgi.com, Linux NFS Mailing List References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <8618458.1EVJCoVbkH@wuerfel> <4178301.j9kWdGCRLC@wuerfel> <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com> <20140602153124.GH30598@thunk.org> <538CB085.5000502@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538CB085.5000502@zytor.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 02, 2014 at 10:12:37AM -0700, H. Peter Anvin wrote: > > It would be problematic for time(2) or gettimeofday(2) to return > > TIME_UNDEFINED, since there are programs that care about time ticking > > forward, but I could imagine a new interface which would be permitted > > to return a flag indicating that we don't know the current time > > (because the CMOS battery had run down, etc.) so instead we're going > > to be counting the number of seconds since the system was booted. > > This assumes that we actually know that that is the case, which may be > an aggressive assumption. We won't know if the RTC clock is wrong, true --- but the kernel will know if (a) the hardware doesn't have RTC clock at all, or if (b) the RTC clock is ticking some time that can't be encoded using the current time_t type. So in that case, the fallback would be to be for the kernel to tick starting with time_t == 0 when the system is initially booted, and the "time indefinite flag" would be set. Now assume that we have a new system call, gettimestampofday(2), which returns a new timestamp structure which has a 64-bit ts_sec field, the ts_nsec field (ala struct timespec), and a ts_flags field, where the kernel could signal things like "time invalid", or "time can't be encoded in the legacy time_t type", or "I'm not sure if the time is correct" --- i.e., because the RTC battery isn't working. Not all hardware might be able to support the last, of course, but if the battery is low, or the system has been exposed to very low temperatures (or large amounts of cosmic radiation, etc.) the RTC time may just be plain wrong. No system is going to be perfect, but it should be possible to make htings better, at for certain classes of hardware. And since we are already returning (time_t) -1 in some cases, we might as well try to make things a bit more formal. - Ted