[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: Chris Friesen on 4 Aug 2010 14:50 On 08/04/2010 09:58 AM, john stultz 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. We actually added a time-change-notification mechanism internally a long time ago but never saw demand for it and so never bothered trying to push it upstream. Ours is signal-based. Among other things we use it to pass on time-change notifications to an emulator running a proprietary OS that really cares about having an accurate time-of-day but can't afford a syscall to retrieve it every time. Chris -- Chris Friesen Software Developer GENBAND chris.friesen(a)genband.com www.genband.com -- 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 4 Aug 2010 21:00 On Wed, 2010-08-04 at 12:48 -0600, Chris Friesen wrote: > On 08/04/2010 09:58 AM, john stultz 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. > > We actually added a time-change-notification mechanism internally a long > time ago but never saw demand for it and so never bothered trying to > push it upstream. Ours is signal-based. > > Among other things we use it to pass on time-change notifications to an > emulator running a proprietary OS that really cares about having an > accurate time-of-day but can't afford a syscall to retrieve it every time. So the eventfd based method (and the filtering) proposed would work for you? thanks -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: Kirill A. Shutemov on 5 Aug 2010 06:10 On Wed, Aug 04, 2010 at 06:46:38PM +0300, Alexander Shishkin wrote: > On Wed, Aug 04, 2010 at 06:32:21 +0300, Kirill A. Shutemov wrote: > > On Wed, Aug 04, 2010 at 03:48:28PM +0300, Alexander Shishkin wrote: > > > Certain userspace applications (like "clock" desktop applets or ntpd) might > > > want to be notified when some other application changes the system time. It > > > might also be important for an application to be able to distinguish between > > > its own and somebody else's time changes. > > > > > > This patch implements a notification interface via eventfd mechanism. Proccess > > > wishing to be notified about time changes should create an eventfd and echo > > > its file descriptor to /sys/kernel/time_notify. After that, any calls to > > > settimeofday()/stime()/adjtimex() made by other processes will be signalled > > > to this eventfd. Credits for suggesting the eventfd mechanism for this > > > purpose go te Kirill Shutemov. > > > > > > So far, this implementation can only filter out notifications caused by > > > time change calls made by the process that wrote the eventfd descriptor to > > > sysfs, but not its children which (might) have inherited the eventfd. It > > > is so far not clear to me whether this is bad and more confusing than > > > excluding such children as well. > > > > I think it's a bad idea to filter notifications. Let's leave it for > > Why? Someone might want to recieve notifications about its own activity. It's a policy. Kernel should provide mechanism, not policy. -- Kirill A. Shutemov -- 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 5 Aug 2010 08:40 On 5 August 2010 03:52, john stultz <johnstul(a)us.ibm.com> wrote: > On Wed, 2010-08-04 at 12:48 -0600, Chris Friesen wrote: >> On 08/04/2010 09:58 AM, john stultz 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. >> >> We actually added a time-change-notification mechanism internally a long >> time ago but never saw demand for it and so never bothered trying to >> push it upstream. Ours is signal-based. >> >> Among other things we use it to pass on time-change notifications to an >> emulator running a proprietary OS that really cares about having an >> accurate time-of-day but can't afford a syscall to retrieve it every time. > > So the eventfd based method (and the filtering) proposed would work for > you? I think that Kirill has a point and the filtering is really there for no gain. The user can indeed count his own time changes and compare that against the eventfd counter. 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 5 Aug 2010 08:40
On 4 August 2010 18:58, john stultz <johnstul(a)us.ibm.com> wrote: > On Wed, 2010-08-04 at 15:48 +0300, Alexander Shishkin wrote: >> Certain userspace applications (like "clock" desktop applets or ntpd) might >> want to be notified when some other application changes the system time. It >> might also be important for an application to be able to distinguish between >> its own and somebody else's time changes. > > So NTP doesn't actually care, as it will notice the STA_UNSYNC flag is > set the next time it checks adjtimex. > > The clock apps example seems reasonable, but maybe isn't the most > compelling argument for adding a new kernel api. > > 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. 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/ |