On Tue, Nov 22, 2016 at 10:39:29AM +0000, David Howells wrote: > Dave Chinner <david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
