From: Dave Chinner <firstname.lastname@example.org> To: David Howells <email@example.com> Cc: Andreas Dilger <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available Date: Wed, 23 Nov 2016 07:58:16 +1100 [thread overview] Message-ID: <20161122205816.GM28177@dastard> (raw) In-Reply-To: <email@example.com> On Tue, Nov 22, 2016 at 10:39:29AM +0000, David Howells wrote: > Dave Chinner <firstname.lastname@example.org> 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 email@example.com
next prev parent reply other threads:[~2016-11-22 20:58 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-11-17 13:34 [RFC][PATCH 0/4] Enhanced file stat system call David Howells 2016-11-17 13:35 ` [PATCH 1/4] statx: Add a system call to make enhanced file info available David Howells 2016-11-17 18:39 ` Jeff Layton 2016-11-18 2:32 ` Andreas Dilger 2016-11-18 8:59 ` David Howells 2016-11-18 8:59 ` David Howells 2016-11-18 9:25 ` Andreas Dilger 2016-11-18 9:25 ` Andreas Dilger 2016-11-17 23:40 ` Dave Chinner 2016-11-18 3:28 ` Andreas Dilger 2016-11-18 22:07 ` Dave Chinner 2016-11-18 22:54 ` David Howells 2016-11-19 22:43 ` Dave Chinner 2016-11-21 14:30 ` One Thousand Gnomes 2016-11-21 20:43 ` Dave Chinner 2016-11-22 10:39 ` David Howells 2016-11-22 13:55 ` Jeff Layton 2016-11-22 20:58 ` Dave Chinner [this message] 2016-11-18 9:53 ` David Howells 2016-11-18 8:48 ` David Howells 2016-11-18 12:01 ` Jeff Layton 2016-11-18 9:36 ` David Howells 2016-11-18 17:17 ` Jeff Layton 2016-11-18 18:04 ` David Howells 2016-11-18 18:54 ` Jeff Layton 2016-11-18 19:08 ` David Howells 2016-11-18 9:43 ` David Howells 2016-11-18 21:41 ` Dave Chinner 2016-11-18 22:24 ` David Howells 2016-11-18 10:29 ` David Howells 2016-11-18 10:29 ` David Howells 2016-11-18 21:27 ` Dave Chinner 2016-11-18 21:48 ` David Howells 2016-11-18 21:48 ` David Howells 2016-11-18 22:17 ` Dave Chinner 2016-11-18 22:17 ` Dave Chinner 2016-11-19 10:21 ` Michael Kerrisk (man-pages) 2016-11-17 13:35 ` [PATCH 2/4] statx: Ext4: Return enhanced file attributes David Howells 2016-11-18 3:30 ` Andreas Dilger 2016-11-17 13:35 ` [PATCH 3/4] statx: NFS: " David Howells 2016-11-17 13:35 ` [PATCH 4/4] statx: AFS: " David Howells 2016-11-18 3:34 ` Andreas Dilger 2016-11-18 8:47 ` David Howells 2016-11-17 14:39 ` [RFC][PATCH 0/4] Enhanced file stat system call One Thousand Gnomes 2016-11-17 15:10 ` Michael Kerrisk 2016-11-17 16:33 ` David Howells 2016-11-17 16:45 ` David Howells 2016-11-17 20:00 ` J. Bruce Fields 2016-11-18 2:30 ` Andreas Dilger 2016-11-18 4:29 ` NeilBrown 2016-11-18 13:41 ` One Thousand Gnomes 2016-11-18 13:49 ` David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20161122205816.GM28177@dastard \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.