From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756949AbcKVU63 (ORCPT ); Tue, 22 Nov 2016 15:58:29 -0500 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:39414 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756915AbcKVU60 (ORCPT ); Tue, 22 Nov 2016 15:58:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcpAK+wNFh5LIq7EGdsb2JhbABdHAEBBAEBCgEBgyoOAQEBAQEfgVmCe4N5nEIBBoEcjCSGO4QUhhsCAgEBAoIaVAECAQEBAQECBgEBAQEBAQI3RUIShBUBAQQnExwjEAgDDgoJJQ8FJQMHGhOIbLFpPYtTAQEIAgEkIIVUhSSKDB4BBJpOkHKQN41mhAyBSBMMhVUqNIUDgwkBAQE Date: Wed, 23 Nov 2016 07:58:16 +1100 From: Dave Chinner To: David Howells Cc: Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available Message-ID: <20161122205816.GM28177@dastard> References: <20161119224331.GE31101@dastard> <20161118220744.GC31101@dastard> <147938969703.13574.10295364502230379833.stgit@warthog.procyon.org.uk> <147938970382.13574.11581172952175034619.stgit@warthog.procyon.org.uk> <20161117234047.GE28177@dastard> <11317.1479509642@warthog.procyon.org.uk> <9047.1479811169@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9047.1479811169@warthog.procyon.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 22, 2016 at 10:39:29AM +0000, David Howells wrote: > Dave Chinner wrote: > > > No. Just provide a 64 bit high resoultion field, and define it to > > contain nanoseconds. When we need higher resolution to be exported > > to userspace, we use a /feature flag/ to indicate that is contains > > something like attoseconds or the like. > > That sounds suspiciously like a bad idea - if you're talking about a flag with > a currently undefined meaning that the kernel can inflict on userspace without > warning to change the meaning of the nanoseconds field to something we haven't > defined yet. > > Userspace would have to ask for it. Yes, of course it would - this would enable userspace to move from struct timespec to something with higher resolution without having to use different structures or guess what the resolution being returned by the kernel is for different filesystems, We had a major mess with the time_t -> struct timespec upgrade of the stat() kernel interface to support nanosecond timestamps in the syscall because when stat() was first designed all those years ago single second resolution was all anyone needed. The original designers of the stat API didn't have 30+ years of history telling them that machines will get faster than anyone could imagine and that timestamps will always get more accurate and increase in resolution. Perhaps people are fine with repeating past mistakes - all I can do is point them out and suggest alternative approaches that will avoid a repeat... Cheers, Dave. -- Dave Chinner david@fromorbit.com