On Tue, 2016-11-22 at 10:39 +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. > Agreed. I think the best thing would be to simply plan to add new femtoseconds fields in the struct if/when it becomes needed. We can easily hide the ugliness of the fields not being adjacent to the rest of the timestamp behind the femtosecond resolution glibc API that will also be needed. If we're worried about space utilization, then let's pad the struct out by 4 extra 32-bit fields in advance of that. Again, a major design point of statx is that it is to be extendable. I don't see any reason that we need to do this now. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
