aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/capability.h
diff options
context:
space:
mode:
authorJohn Stultz <john.stultz@linaro.org>2011-01-11 12:54:33 -0500
committerJohn Stultz <john.stultz@linaro.org>2011-04-26 17:01:46 -0400
commit9a7adcf5c6dea63d2e47e6f6d2f7a6c9f48b9337 (patch)
tree151f7fbb135053945fc6eae99c9175e860ad343c /include/linux/capability.h
parentff3ead96d17f47ee70c294a5cc2cce9b61e82f0f (diff)
timers: Posix interface for alarm-timers
This patch exposes alarm-timers to userland via the posix clock and timers interface, using two new clockids: CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM. Both clockids behave identically to CLOCK_REALTIME and CLOCK_BOOTTIME, respectively, but timers set against the _ALARM suffixed clockids will wake the system if it is suspended. Some background can be found here: https://lwn.net/Articles/429925/ The concept for Alarm-timers was inspired by the Android Alarm driver (by Arve Hjønnevåg) found in the Android kernel tree. See: http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=drivers/rtc/alarm.c;h=1250edfbdf3302f5e4ea6194847c6ef4bb7beb1c;hb=android-2.6.36 While the in-kernel interface is pretty similar between alarm-timers and Android alarm driver, the user-space interface for the Android alarm driver is via ioctls to a new char device. As mentioned above, I've instead chosen to export this functionality via the posix interface, as it seemed a little simpler and avoids creating duplicate interfaces to things like CLOCK_REALTIME and CLOCK_MONOTONIC under alternate names (ie:ANDROID_ALARM_RTC and ANDROID_ALARM_SYSTEMTIME). The semantics of the Android alarm driver are different from what this posix interface provides. For instance, threads other then the thread waiting on the Android alarm driver are able to modify the alarm being waited on. Also this interface does not allow the same wakelock semantics that the Android driver provides (ie: kernel takes a wakelock on RTC alarm-interupt, and holds it through process wakeup, and while the process runs, until the process either closes the char device or calls back in to wait on a new alarm). One potential way to implement similar semantics may be via the timerfd infrastructure, but this needs more research. There may also need to be some sort of sysfs system level policy hooks that allow alarm timers to be disabled to keep them from firing at inappropriate times (ie: laptop in a well insulated bag, mid-flight). CC: Arve Hjønnevåg <arve@android.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Alessandro Zummo <a.zummo@towertech.it> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
Diffstat (limited to 'include/linux/capability.h')
-rw-r--r--include/linux/capability.h7
1 files changed, 6 insertions, 1 deletions
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 16ee8b49a200..7cb23eae693d 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -355,7 +355,12 @@ struct cpu_vfs_cap_data {
355 355
356#define CAP_SYSLOG 34 356#define CAP_SYSLOG 34
357 357
358#define CAP_LAST_CAP CAP_SYSLOG 358/* Allow triggering something that will wake the system */
359
360#define CAP_WAKE_ALARM 35
361
362
363#define CAP_LAST_CAP CAP_WAKE_ALARM
359 364
360#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP) 365#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
361 366