[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 5 Aug 2010 10:30 On 08/04/2010 06:52 PM, john stultz 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? The eventfd based method would work. The filtering is unnecessary for us and seems somewhat fragile as currently implemented. 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 5 Aug 2010 17:20 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? 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: Greg KH on 5 Aug 2010 17:40 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 :) thanks, greg k-h -- 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: Kay Sievers on 5 Aug 2010 18:20 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. 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: Kay Sievers on 5 Aug 2010 18:30
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. :) 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/ |