On Thu, Mar 10, 2011 at 01:25, Andrew Morton [off-list ref] wrote:
On Wed, 9 Mar 2011 16:36:51 +0200
Alexander Shishkin [off-list ref] wrote:
quoted
Changes since v3:
- changed timerfd_settime() semantics (see below)
Changes since v2:
- replaced sysfs interface with a syscall
- added sysctl/procfs handle to set a limit to the number of users
- fixed issues pointed out by Greg.
Changes since v1:
- updated against 2.6.36-rc1,
- added notification/filtering options,
- added Documentation/ABI/sysfs-kernel-time-notify interface description.
It would be helpful to know if the identified users of this feature
actually find it useful and adequate. I guess the most common
application is the 1,001 desktop clock widgets. Do you have any
feedback from any of the owners of those?
We want it for systemd, to provide cron-like functionality but without
the need to stupidly wake up every minute and check the system time
for possible jumps.
It also sounds useful for a generic resume (after system suspend)
notification for applications, which isn't really possible today.
Kay
On Thu, Mar 10, 2011 at 01:36:18AM +0100, Kay Sievers wrote:
On Thu, Mar 10, 2011 at 01:25, Andrew Morton [off-list ref] wrote:
quoted
On Wed, 9 Mar 2011 16:36:51 +0200
Alexander Shishkin [off-list ref] wrote:
quoted
Changes since v3:
- changed timerfd_settime() semantics (see below)
Changes since v2:
- replaced sysfs interface with a syscall
- added sysctl/procfs handle to set a limit to the number of users
- fixed issues pointed out by Greg.
Changes since v1:
- updated against 2.6.36-rc1,
- added notification/filtering options,
- added Documentation/ABI/sysfs-kernel-time-notify interface description.
quoted
It would be helpful to know if the identified users of this feature
actually find it useful and adequate. I guess the most common
application is the 1,001 desktop clock widgets. Do you have any
feedback from any of the owners of those?
We want it for systemd, to provide cron-like functionality but without
the need to stupidly wake up every minute and check the system time
for possible jumps.
It also sounds useful for a generic resume (after system suspend)
notification for applications, which isn't really possible today.
Yes, but with John's CLOCK_BOOTTIME patches (which are in the tip tree
currently) it will be.
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 10 Mar 2011, Kay Sievers wrote:
On Thu, Mar 10, 2011 at 01:25, Andrew Morton [off-list ref] wrote:
quoted
On Wed, 9 Mar 2011 16:36:51 +0200
Alexander Shishkin [off-list ref] wrote:
quoted
Changes since v3:
- changed timerfd_settime() semantics (see below)
Changes since v2:
- replaced sysfs interface with a syscall
- added sysctl/procfs handle to set a limit to the number of users
- fixed issues pointed out by Greg.
Changes since v1:
- updated against 2.6.36-rc1,
- added notification/filtering options,
- added Documentation/ABI/sysfs-kernel-time-notify interface description.
quoted
It would be helpful to know if the identified users of this feature
actually find it useful and adequate. I guess the most common
application is the 1,001 desktop clock widgets. Do you have any
feedback from any of the owners of those?
We want it for systemd, to provide cron-like functionality but without
the need to stupidly wake up every minute and check the system time
for possible jumps.
It also sounds useful for a generic resume (after system suspend)
notification for applications, which isn't really possible today.
Note, that we have CLOCK_BOOTTIME pending for .39 which aims at the
same problem. It's basically CLOCK_MONOTONIC adjusted by the time we
were in suspend. So while CLOCK_MONOTONIC timers are not aware of the
time spent in suspend CLOCK_BOOTTIME timers are. The reason for
implementing CLOCK_BOOTTIME was basically the same problem.
Thanks,
tglx