lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Dec 2011 13:03:26 +0100 From: Richard Cochran <richardcochran@...il.com> To: john stultz <johnstul@...ibm.com> Cc: Andy Lutomirski <luto@...capital.net>, linux-kernel@...r.kernel.org, Kumar Sundararajan <kumar@...com>, Arun Sharma <asharma@...com>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [RFC 0/2] ABI for clock_gettime_ns On Wed, Dec 14, 2011 at 11:07:46AM -0800, john stultz wrote: > On Wed, 2011-12-14 at 19:30 +0100, Richard Cochran wrote: > > > > So, you agree on adding new syscalls as a performance tweek? > > Well, the patch that started this off was introducing a new vdso > function (which had no syscall equivalent) that provided the same data > as clock_gettime(CLOCK_THREAD_CPUTIME,...) but in ns format, because > that was a reasonable performance win. I don't see anything CLOCK_THREAD_CPUTIME in the patches, but I do see CLOCK_REALTIME and CLOCK_MONOTONIC. How is this about thread CPU time? (I assumed it was about fast time stamps.) > I don't think what is being proposed is trying to limit its use cases. > The only limitation api wise was if we should return just nanoseconds or > something with the potential for sub-ns values. Yes, I do think new interfaces should anticipate sub-ns uses. > > I mean to define an interface that always returns TAI values, no matter > > what the clock device. > > Maybe I'm still not understanding, but that seems more limited then what > is being proposed, at least in my mind. clock_gettime_ns() would still > take a clockid, so having a CLOCK_TAI would be a potential change in the > future. POSIX got the clock_gettime interface wrong, because you cannot tell the time with it. The POSIX interface will return the same time value for two consecutive seconds, due to leap seconds. IMHO, new interfaces should correct this mistake. So, a new interface providing UTC should also tell the user about leap seconds. Just my 2 cents, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists