On Wed, 9 Mar 2011 16:36:51 +0200
Alexander Shishkin [off-list ref] wrote:
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.
Certain userspace applications (like "clock" desktop applets or cron or
systemd) might want to be notified when some other application changes
the system time. There are several known to me reasons for this:
- avoiding periodic wakeups to poll time changes;
- rearming CLOCK_REALTIME timers when said changes happen;
- changing system timekeeping policy for system-wide time management
programs;
- keeping guest applications/operating systems running in emulators
up to date;
- recalculation of traffic signal cycles in Advanced Traffic Controllers
(ATC), which is part of ATC API requirements [1] as developed by ATC
working group of the U.S. Institute of Transportation Engineers (ITE).
The major change since the previous version is the new semantics of
timerfd_settime() when it's called on a time change notification
descriptor: it will set the system time to utmr.it_value if the time
change counter is zero, otherwise it will return EBUSY, this is required
to prevent a race between setting the time and reading the counter, when
the time controlling procees changes the time immediately after another
process in the system did the same (the counter is greater than one),
that process' time change will be lost. Thus, the time controlling
process should use timerfd_settime() instead of clock_settime() or
settimeofday() to ensure that other processes' time changes don't get
lost.
This is another attempt to approach notifying userspace about system
clock changes. The other one is using an eventfd and a syscall [1]. In
the course of discussing the necessity of a syscall for this kind of
notifications, it was suggested that this functionality can be achieved
via timers [2] (and timerfd in particular [3]). This idea got quite
some support [4], [5], [6] and some vague criticism [7], so I decided
to try and go a bit further with it.
Looks sane to me. The changelog is a bit of a pickle - I stole a
useful-looking paragraph from your other please-ignore-this-email
email.
I also cc'ed Michael and linux-api: there isn't much point in adding
kernel features if we don't tell anyone about them.
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?
Thanks.
On Wed, Mar 09, 2011 at 04:25:13PM -0800, Andrew Morton 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.
Certain userspace applications (like "clock" desktop applets or cron or
systemd) might want to be notified when some other application changes
the system time. There are several known to me reasons for this:
- avoiding periodic wakeups to poll time changes;
- rearming CLOCK_REALTIME timers when said changes happen;
- changing system timekeeping policy for system-wide time management
programs;
- keeping guest applications/operating systems running in emulators
up to date;
- recalculation of traffic signal cycles in Advanced Traffic Controllers
(ATC), which is part of ATC API requirements [1] as developed by ATC
working group of the U.S. Institute of Transportation Engineers (ITE).
The major change since the previous version is the new semantics of
timerfd_settime() when it's called on a time change notification
descriptor: it will set the system time to utmr.it_value if the time
change counter is zero, otherwise it will return EBUSY, this is required
to prevent a race between setting the time and reading the counter, when
the time controlling procees changes the time immediately after another
process in the system did the same (the counter is greater than one),
that process' time change will be lost. Thus, the time controlling
process should use timerfd_settime() instead of clock_settime() or
settimeofday() to ensure that other processes' time changes don't get
lost.
This is another attempt to approach notifying userspace about system
clock changes. The other one is using an eventfd and a syscall [1]. In
the course of discussing the necessity of a syscall for this kind of
notifications, it was suggested that this functionality can be achieved
via timers [2] (and timerfd in particular [3]). This idea got quite
some support [4], [5], [6] and some vague criticism [7], so I decided
to try and go a bit further with it.
Looks sane to me. The changelog is a bit of a pickle - I stole a
useful-looking paragraph from your other please-ignore-this-email
email.
I was trying to word it so that I wouldn't have to explain the same things
over and over again after each patch version. :) But your version looks
better.
I also cc'ed Michael and linux-api: there isn't much point in adding
kernel features if we don't tell anyone about them.
Yep, they somehow dropped out of my CC list in one of the previous
versions. I can provide a patch for man-pages, of course.
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?
Shaun Reich (KDE) and Ken MacLeod (ITE) have contacted me recently asking
about my progress with this feature. They, as well as other potential
users for this are in CC. Their feedback was how I came up with the list
of usecases above.
Thanks,
--
Alex