On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote:
>
> I think that coming up with something that's both non-POSIX and
> half-arsed is a bad idea, but doing something that's non-POSIX and
> well thought-through could be valuable.
I know Harlan Stenn of the Network Time Foundation
On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote:
I think that coming up with something that's both non-POSIX and
half-arsed is a bad idea, but doing something that's non-POSIX and
well thought-through could be valuable.
I know Harlan Stenn of the Network Time Foundation is
On Wed, Sep 4, 2013 at 6:22 PM, H. Peter Anvin wrote:
> I think it would be crazy encoding UTC with a non-POSIX scheme.
The whole point is to find a good way to return the time that solves
the problems with the POSIX scheme. Some of the problems, as I see
them, are:
- Performance: seconds +
On Wed, Sep 4, 2013 at 6:22 PM, H. Peter Anvin h...@zytor.com wrote:
I think it would be crazy encoding UTC with a non-POSIX scheme.
The whole point is to find a good way to return the time that solves
the problems with the POSIX scheme. Some of the problems, as I see
them, are:
-
On 9/5/13 12:47 AM, John Stultz wrote:
If we're going to add a new interface that uses something other then a
timespec, we likely need to put some serious thought into that new
type, and see how it could be used across a number of syscalls. Some
of the discussion around dealing with the 2038
I think it would be crazy encoding UTC with a non-POSIX scheme.
Andy Lutomirski wrote:
>On Wed, Sep 4, 2013 at 3:29 PM, H. Peter Anvin wrote:
>> On 09/04/2013 01:54 PM, John Stultz wrote:
I'd advocate for going whole hog and returning, atomically:
- TAI (nanoseconds from
On Wed, Sep 4, 2013 at 3:29 PM, H. Peter Anvin wrote:
> On 09/04/2013 01:54 PM, John Stultz wrote:
>>>
>>> I'd advocate for going whole hog and returning, atomically:
>>>
>>> - TAI (nanoseconds from epoch)
>>> - UTC - TAI (seconds or nanoseconds) *
>>> - TAI - CLOCK_MONOTONIC (nanoseconds)
>>>
On 09/04/2013 04:04 PM, H. Peter Anvin wrote:
> On 09/04/2013 03:59 PM, John Stultz wrote:
>> Also, there's been talk of a slewed-leap-second clockid, basically UTC
>> but around the leapsecond it slows down to absorb the extra second. This
>> means that clockid would have a subsecond offset from
On 09/04/2013 03:59 PM, John Stultz wrote:
>
> Also, there's been talk of a slewed-leap-second clockid, basically UTC
> but around the leapsecond it slows down to absorb the extra second. This
> means that clockid would have a subsecond offset from TAI.
>
Most of what I have heard seem to
On 09/04/2013 03:29 PM, H. Peter Anvin wrote:
> On 09/04/2013 01:54 PM, John Stultz wrote:
>>> I'd advocate for going whole hog and returning, atomically:
>>>
>>> - TAI (nanoseconds from epoch)
>>> - UTC - TAI (seconds or nanoseconds) *
>>> - TAI - CLOCK_MONOTONIC (nanoseconds)
>>> - a leap
On 09/04/2013 01:54 PM, John Stultz wrote:
>>
>> I'd advocate for going whole hog and returning, atomically:
>>
>> - TAI (nanoseconds from epoch)
>> - UTC - TAI (seconds or nanoseconds) *
>> - TAI - CLOCK_MONOTONIC (nanoseconds)
>> - a leap second flag.
>>
>> * There are various ways to define
On 09/04/2013 01:23 PM, Andy Lutomirski wrote:
> On Wed, Sep 4, 2013 at 12:17 PM, John Stultz wrote:
>> On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma wrote:
>>> A couple of years ago Andy posted this patch series:
>>>
>>> http://thread.gmane.org/gmane.linux.kernel/1233209/
>>>
>>> These patches
On 09/04/2013 01:33 PM, Andy Lutomirski wrote:
> On Wed, Sep 4, 2013 at 12:20 PM, John Stultz wrote:
>> On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski wrote:
>>> I think that most of the hangup was a lack of agreement on how the API
>>> should work wrt leap seconds.
>> I don't recall this
On Wed, Sep 4, 2013 at 12:20 PM, John Stultz wrote:
> On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski wrote:
>> I think that most of the hangup was a lack of agreement on how the API
>> should work wrt leap seconds.
>
> I don't recall this objection. The interface uses existing clockids,
> so
On Wed, Sep 4, 2013 at 12:17 PM, John Stultz wrote:
> On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma wrote:
>> A couple of years ago Andy posted this patch series:
>>
>> http://thread.gmane.org/gmane.linux.kernel/1233209/
>>
>> These patches have been in use at facebook for a couple of years and
On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski wrote:
> I think that most of the hangup was a lack of agreement on how the API
> should work wrt leap seconds.
I don't recall this objection. The interface uses existing clockids,
so it probably should keep the existing leap-second behavior of
On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma wrote:
> A couple of years ago Andy posted this patch series:
>
> http://thread.gmane.org/gmane.linux.kernel/1233209/
>
> These patches have been in use at facebook for a couple of years and along
> with a vDSO implementation of thread_cpu_time(), they
I think that most of the hangup was a lack of agreement on how the API
should work wrt leap seconds.
I've always thought that the Right Way to represent a UTC time is
nanoseconds since some epoch, where every potential leap second
counts.
Pros:
- Unambiguously convertible to and from
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
These patches have been in use at facebook for a couple of years and
along with a vDSO implementation of thread_cpu_time(), they have proven
useful for our profilers.
I didn't see any
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
These patches have been in use at facebook for a couple of years and
along with a vDSO implementation of thread_cpu_time(), they have proven
useful for our profilers.
I didn't see any
I think that most of the hangup was a lack of agreement on how the API
should work wrt leap seconds.
I've always thought that the Right Way to represent a UTC time is
nanoseconds since some epoch, where every potential leap second
counts.
Pros:
- Unambiguously convertible to and from
On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma asha...@fb.com wrote:
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
These patches have been in use at facebook for a couple of years and along
with a vDSO implementation of
On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski l...@amacapital.net wrote:
I think that most of the hangup was a lack of agreement on how the API
should work wrt leap seconds.
I don't recall this objection. The interface uses existing clockids,
so it probably should keep the existing
On Wed, Sep 4, 2013 at 12:17 PM, John Stultz john.stu...@linaro.org wrote:
On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma asha...@fb.com wrote:
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
These patches have been in use at facebook for
On Wed, Sep 4, 2013 at 12:20 PM, John Stultz john.stu...@linaro.org wrote:
On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski l...@amacapital.net wrote:
I think that most of the hangup was a lack of agreement on how the API
should work wrt leap seconds.
I don't recall this objection. The
On 09/04/2013 01:33 PM, Andy Lutomirski wrote:
On Wed, Sep 4, 2013 at 12:20 PM, John Stultz john.stu...@linaro.org wrote:
On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski l...@amacapital.net wrote:
I think that most of the hangup was a lack of agreement on how the API
should work wrt leap
On 09/04/2013 01:23 PM, Andy Lutomirski wrote:
On Wed, Sep 4, 2013 at 12:17 PM, John Stultz john.stu...@linaro.org wrote:
On Wed, Sep 4, 2013 at 2:18 AM, Arun Sharma asha...@fb.com wrote:
A couple of years ago Andy posted this patch series:
http://thread.gmane.org/gmane.linux.kernel/1233209/
On 09/04/2013 01:54 PM, John Stultz wrote:
I'd advocate for going whole hog and returning, atomically:
- TAI (nanoseconds from epoch)
- UTC - TAI (seconds or nanoseconds) *
- TAI - CLOCK_MONOTONIC (nanoseconds)
- a leap second flag.
* There are various ways to define this. My fancy
On 09/04/2013 03:29 PM, H. Peter Anvin wrote:
On 09/04/2013 01:54 PM, John Stultz wrote:
I'd advocate for going whole hog and returning, atomically:
- TAI (nanoseconds from epoch)
- UTC - TAI (seconds or nanoseconds) *
- TAI - CLOCK_MONOTONIC (nanoseconds)
- a leap second flag.
*
On 09/04/2013 03:59 PM, John Stultz wrote:
Also, there's been talk of a slewed-leap-second clockid, basically UTC
but around the leapsecond it slows down to absorb the extra second. This
means that clockid would have a subsecond offset from TAI.
Most of what I have heard seem to center
On 09/04/2013 04:04 PM, H. Peter Anvin wrote:
On 09/04/2013 03:59 PM, John Stultz wrote:
Also, there's been talk of a slewed-leap-second clockid, basically UTC
but around the leapsecond it slows down to absorb the extra second. This
means that clockid would have a subsecond offset from TAI.
On Wed, Sep 4, 2013 at 3:29 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/04/2013 01:54 PM, John Stultz wrote:
I'd advocate for going whole hog and returning, atomically:
- TAI (nanoseconds from epoch)
- UTC - TAI (seconds or nanoseconds) *
- TAI - CLOCK_MONOTONIC (nanoseconds)
- a
I think it would be crazy encoding UTC with a non-POSIX scheme.
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Sep 4, 2013 at 3:29 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/04/2013 01:54 PM, John Stultz wrote:
I'd advocate for going whole hog and returning, atomically:
- TAI
On 9/5/13 12:47 AM, John Stultz wrote:
If we're going to add a new interface that uses something other then a
timespec, we likely need to put some serious thought into that new
type, and see how it could be used across a number of syscalls. Some
of the discussion around dealing with the 2038
34 matches
Mail list logo
