[PATCH 0/2] [RFC] Introduce CLOCK_BOOTTIME

[John Stultz]

After some discussions with Jamie Lokier about some of the 
drawbacks of CLOCK_MONOTONIC not incrementing during suspend
(see http://www.spinics.net/lists/linux-fsdevel/msg40272.html),
I wanted to see if we couldn't provide a new clockid that would 
allow applications that wanted to be aware of time passing during
suspend without having to deal with the inconsistencies of 
CLOCK_REALTIME caused by calls to settimeofday.

So this patchset introduces CLOCK_BOOTTIME, which is identical
to CLOCK_MONOTONIC, but includes any time spent in suspend.

This is just my initial stab at this, so I'd appreciate any comments
or thougths on these patches.

Jamie: On platforms that don't implement read_persistent_clock,
your issue would still be present, but fixing that is on my list.
Other then that issue, does this seem to address your concern?

Thomas: Let me know if the hrtimer_base indirection is too 
gross. It just seemed silly to create 5 empty bases so we could
have an exact match between the clockids and the bases.

Arve: I believe CLOCK_BOOTTIME would be sufficient for what
Android is using as elapsedRealtime() or 
ANDROID_ALARM_ELAPSED_REALTIME. If not please let me know why.

thanks
-john


CC: Jamie Lokier <jamie@xxxxxxxxxxxxx>
CC: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
CC: Alexander Shishkin <virtuoso@xxxxxxxxx>
CC: Arve Hjønnevåg <arve@xxxxxxxxxxx>


John Stultz (2):
  hrtimers: extend hrtimer base code to handle more then 2 clockids
  hrtimers: Add CLOCK_BOOTTIME clockid, hrtimerbase and posix interface

 include/linux/hrtimer.h   |   22 ++++++++++++-
 include/linux/time.h      |    4 ++
 kernel/hrtimer.c          |   44 ++++++++++++++++---------
 kernel/posix-timers.c     |   16 ++++++++-
 kernel/time/timekeeping.c |   79 ++++++++++++++++++++++++++++++++++++++++++++-
 5 files changed, 146 insertions(+), 19 deletions(-)

-- 
1.7.3.2.146.gca209

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/