[RFC] notify userspace about time changes
in [Kernel]
|
Prev: linux-next: build failure after merge of the final tree (nfs tree related)
Next: [GIT] kbuild: packaging
From: Kay Sievers on 5 Aug 2010 20:00 On Fri, Aug 6, 2010 at 00:29, john stultz <johnstul(a)us.ibm.com> wrote: > On Fri, 2010-08-06 at 00:17 +0200, Kay Sievers wrote: >> On Thu, Aug 5, 2010 at 23:11, john stultz <johnstul(a)us.ibm.com> wrote: >> > On Thu, 2010-08-05 at 15:33 +0300, Alexander Shishkin wrote: >> >> On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: >> >> > Is there a actual use case that you need this for? I don't really have >> >> > an issue with the code I just really want to make sure the feature would >> >> > be useful enough to justify the API and code maintenance going forward. >> >> Basically everything that schedules an action based on an absolute >> time specification, like at 3pm today, and not in 3 hours from now, >> needs to track such system time changes. Otherwise it has to do >> nonsense like cron does, to wake up every minute to check the current >> time. > > time_create(CLOCK_REALTIME,...) creates absolute (not relative) timers > that should be adjusted when the clock is changed. Is that not the case? That works, yes. The created timer is still is a fixed value, and it gets automatically adjusted when the system time changes. This is the example Lennart and I thought about when we considered adding cron-like stuff to systemd's timer configs, but didn't want to do silly things like scheduled checks for the actual time, so we delayed this feature until such a notification becomes available. Consider we want stuff like "wakeup every day at 3pm", the next wakeup might be earlier than the timer we calculated last time, on system time changes. We need to re-calculate it. This is necessary for all repeating events. Say we want to wakeup at 3pm, now it's 4pm, so we schedule it in 23 hours. Now the system time changes to 2pm, and we would expect to wakeup in one hour, but we take 25. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on 5 Aug 2010 20:20 On Fri, 2010-08-06 at 01:50 +0200, Kay Sievers wrote: > On Fri, Aug 6, 2010 at 00:29, john stultz <johnstul(a)us.ibm.com> wrote: > > On Fri, 2010-08-06 at 00:17 +0200, Kay Sievers wrote: > >> On Thu, Aug 5, 2010 at 23:11, john stultz <johnstul(a)us.ibm.com> wrote: > >> > On Thu, 2010-08-05 at 15:33 +0300, Alexander Shishkin wrote: > >> >> On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: > >> >> > Is there a actual use case that you need this for? I don't really have > >> >> > an issue with the code I just really want to make sure the feature would > >> >> > be useful enough to justify the API and code maintenance going forward. > >> > >> Basically everything that schedules an action based on an absolute > >> time specification, like at 3pm today, and not in 3 hours from now, > >> needs to track such system time changes. Otherwise it has to do > >> nonsense like cron does, to wake up every minute to check the current > >> time. > > > > time_create(CLOCK_REALTIME,...) creates absolute (not relative) timers > > that should be adjusted when the clock is changed. Is that not the case? > > That works, yes. The created timer is still is a fixed value, and it > gets automatically adjusted when the system time changes. > > This is the example Lennart and I thought about when we considered > adding cron-like stuff to systemd's timer configs, but didn't want to > do silly things like scheduled checks for the actual time, so we > delayed this feature until such a notification becomes available. > > Consider we want stuff like "wakeup every day at 3pm", the next wakeup > might be earlier than the timer we calculated last time, on system > time changes. We need to re-calculate it. This is necessary for all > repeating events. > > Say we want to wakeup at 3pm, now it's 4pm, so we schedule it in 23 > hours. Now the system time changes to 2pm, and we would expect to > wakeup in one hour, but we take 25. Ah. Yea. So its not really an issue scheduling absolute times, but issues around absolute recurrences when time might go backwards. So yea, that's another good example in favor of Alexander's patch (at least the basic functionality, modulo the interface details/documentation). Thanks for the clarification! -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Shishkin on 6 Aug 2010 03:20 On Fri, Aug 06, 2010 at 12:22:27 +0200, Kay Sievers wrote: > On Thu, Aug 5, 2010 at 23:38, Greg KH <gregkh(a)suse.de> wrote: > > On Thu, Aug 05, 2010 at 02:11:05PM -0700, john stultz wrote: > >> On Thu, 2010-08-05 at 15:33 +0300, Alexander Shishkin wrote: > >> > On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: > >> > > Is there a actual use case that you need this for? �I don't really have > >> > > an issue with the code I just really want to make sure the feature would > >> > > be useful enough to justify the API and code maintenance going forward. > >> > > >> > Yes. What we have here is an application which takes care of different means > >> > of time synchronization (trusted time servers, different GSM operators, etc) > >> > and also different kinds of time-based events/notifications (like "dentist > >> > appointment next thursday"). When it encounters a time change that is > >> > made by some other application, it basically wants to disable automatic > >> > time adjustment and trigger the events/notifications which are due at this > >> > (new) time. > >> > >> Ok. Something specific is always more helpful then theoretical uses. > >> > >> I think the filtering is still a bit controversial, so you might want to > >> respin it without that. But otherwise I'm ok with it as long as no one > >> else objects to any of the minor details of the interface > >> > >> GregKH: Does /sys/kernel/time_notify seem ok by you? > > > > Um, it depends, what is that file going to do? �I don't see a > > Documentation/ABI/ entry here that describes it fully :) > > I think that's really awkward interface, to pass file descriptor > numbers around and write them to magic sysfs files. Unfortunately, the magic file descriptor is the only viable option for us (see the usecase I described earlier), for a simple reason that it gives you the *number of times* the system time has changed so that the user can see when someone else is changing the time, for example. Plus, using the magic sysfs file you can specify what kind of events you want to subscribe to, eventually. Like "everything but my changes", "only my changes", "everything", etc. It can be extendable. > I would very much prefer a file that contains the current time, and > wakes up possible users with a POLL_ERR on changes caused by some > other process. That works very well for things like /proc/mounts, is > easy to get, and does not need a full page of weird instructions to > get stuff done. :) So you get a POLLERR because there was a time change that you expected and then someone who wants his time change to go unnoticed changes it again before you started polling again. Full page of weird instructions you are referring to is as follows (sans error checking): efd = eventfd(0, 0); fd = open("/sys/kernel/time_notify", O_WRONLY); fdprintf(fd, "%d", efd); close(fd); fds[0].fd = efd; fds[0].events = POLLIN; while (poll(fds, 1, -1) > 0) { uint64_t n; read(efd, &n, 8); printf("system time has been modified %d time(s)\n", n); } Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Shishkin on 6 Aug 2010 03:30 On Thu, Aug 05, 2010 at 03:38:54 -0700, Greg KH wrote: > On Fri, Aug 06, 2010 at 12:22:27AM +0200, Kay Sievers wrote: > > On Thu, Aug 5, 2010 at 23:38, Greg KH <gregkh(a)suse.de> wrote: > > > On Thu, Aug 05, 2010 at 02:11:05PM -0700, john stultz wrote: > > >> On Thu, 2010-08-05 at 15:33 +0300, Alexander Shishkin wrote: > > >> > On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: > > >> > > Is there a actual use case that you need this for? �I don't really have > > >> > > an issue with the code I just really want to make sure the feature would > > >> > > be useful enough to justify the API and code maintenance going forward. > > >> > > > >> > Yes. What we have here is an application which takes care of different means > > >> > of time synchronization (trusted time servers, different GSM operators, etc) > > >> > and also different kinds of time-based events/notifications (like "dentist > > >> > appointment next thursday"). When it encounters a time change that is > > >> > made by some other application, it basically wants to disable automatic > > >> > time adjustment and trigger the events/notifications which are due at this > > >> > (new) time. > > >> > > >> Ok. Something specific is always more helpful then theoretical uses. > > >> > > >> I think the filtering is still a bit controversial, so you might want to > > >> respin it without that. But otherwise I'm ok with it as long as no one > > >> else objects to any of the minor details of the interface > > >> > > >> GregKH: Does /sys/kernel/time_notify seem ok by you? > > > > > > Um, it depends, what is that file going to do? �I don't see a > > > Documentation/ABI/ entry here that describes it fully :) > > > > I think that's really awkward interface, to pass file descriptor > > numbers around and write them to magic sysfs files. > > Ick, really? That's not ok for sysfs. This is how cgroups notifications work [1], for example. One obtains an eventfd, one then writes its descriptor to a certain control file, one polls said eventfd for events. The type of event is echoed to the same control file together with the fd. So, my idea was, basically to use the sysfs file as means to specify what kind of time-related events a program wants to subscribe to. For example, <int:eventfd descriptor> <bool:want other's time changes> <bool:want own time changes> <bool:want settimeofday> <bool:want adjtime> > > I would very much prefer a file that contains the current time, and > > wakes up possible users with a POLL_ERR on changes caused by some > > other process. That works very well for things like /proc/mounts, is > > easy to get, and does not need a full page of weird instructions to > > get stuff done. :) > > That sounds more reasonable. Polling a simple sysfs file is not enough as I described in the other mail, unless it implements a counter similar to eventfd, which would effectively make it another eventfd implementation, only with a dentry this time. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/cgroup.c;h=a8ce099544049e787464c3e4261ac70625cc0653;hb=HEAD#l3071 onwards Regards, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bastien ROUCARIES on 6 Aug 2010 03:50
On Fri, Aug 6, 2010 at 12:22 AM, Kay Sievers <kay.sievers(a)vrfy.org> wrote: > On Thu, Aug 5, 2010 at 23:38, Greg KH <gregkh(a)suse.de> wrote: >> On Thu, Aug 05, 2010 at 02:11:05PM -0700, john stultz wrote: >>> On Thu, 2010-08-05 at 15:33 +0300, Alexander Shishkin wrote: >>> > On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: >>> > > Is there a actual use case that you need this for? �I don't really have >>> > > an issue with the code I just really want to make sure the feature would >>> > > be useful enough to justify the API and code maintenance going forward. >>> > >>> > Yes. What we have here is an application which takes care of different means >>> > of time synchronization (trusted time servers, different GSM operators, etc) >>> > and also different kinds of time-based events/notifications (like "dentist >>> > appointment next thursday"). When it encounters a time change that is >>> > made by some other application, it basically wants to disable automatic >>> > time adjustment and trigger the events/notifications which are due at this >>> > (new) time. >>> >>> Ok. Something specific is always more helpful then theoretical uses. >>> >>> I think the filtering is still a bit controversial, so you might want to >>> respin it without that. But otherwise I'm ok with it as long as no one >>> else objects to any of the minor details of the interface >>> >>> GregKH: Does /sys/kernel/time_notify seem ok by you? >> >> Um, it depends, what is that file going to do? �I don't see a >> Documentation/ABI/ entry here that describes it fully :) > > I think that's really awkward interface, to pass file descriptor > numbers around and write them to magic sysfs files. > > I would very much prefer a file that contains the current time, and > wakes up possible users with a POLL_ERR on changes caused by some > other process. That works very well for things like /proc/mounts, is > easy to get, and does not need a full page of weird instructions to > get stuff done. :) > See http://lwn.net/Articles/323658/ and it is plan9 compatible Bastien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |