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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXwQXnRRAUZ+h=kR4wUVyfAQyGRd==W47W7LsW7Ci-KAw@mail.gmail.com>
Date:	Wed, 14 Dec 2011 11:20:52 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	john stultz <johnstul@...ibm.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	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 AM, john stultz <johnstul@...ibm.com> wrote:
> I don't see a reason to limit clock_gettime_ns() to only CLOCK_TAI.
> After all, while CLOCK_TAI doesn't have leapseconds, it still can be set
> by userland if its wrong, so it doesn't provide the same functionality
> as CLOCK_MONOTONIC. Additionally, the motivation for this new interface
> is for a more efficient CLOCK_THREAD_CPUTIME vdso implementation, so an
> exclusive CLOCK_TAI interface wouldn't serve that need.
>
> I agree adding CLOCK_TAI is an interesting feature, but that could done
> properly with the existing clock_gettime() interface. So I think the
> CLOCK_TAI discussion is really disconnected from the new ABI being
> proposed.

Unless we want the future CLOCK_TAI to also return the UTC offset (or
vice versa), in which case we can use 32 bits of the padding field for
exactly that purpose.  (If TAI and UTC diverge by more than 2^32
seconds, we probably have other things to worry about.  That being
said, it might be useful to add a little more padding at the cost of a
bit of performance.)

--Andy
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ