Prev: linux-next: build failure after merge of the final tree (nfs tree related)
Next: [GIT] kbuild: packaging
From: Bastien ROUCARIES on 4 Aug 2010 09:00
On Wed, Aug 4, 2010 at 2:48 PM, Alexander Shishkin <virtuoso(a)slind.org> 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.

Why not implementing somtehing like http://lwn.net/Articles/323658/ a
la plan 9 with a poll callback ?

It will be plan9 compatible and so unix

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/
From: Kirill A. Shutemov on 4 Aug 2010 11:40
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
userspace. Userspace always can check eventfd counter and understand who
touch time based on its own activity.

> Similar mechanism can also be used for signalling other (all?) system calls
> made by certain (all?) processes without resorting to ptrace (which won't
> help if you don't know what processes you'd like to look after), given
> proper permission checks etc.
>
> Signed-off-by: Alexander Shishkin <virtuoso(a)slind.org>
> CC: Kirill A. Shutemov <kirill(a)shutemov.name>
> CC: Thomas Gleixner <tglx(a)linutronix.de>
> CC: John Stultz <johnstul(a)us.ibm.com>
> CC: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
> CC: Andrew Morton <akpm(a)linux-foundation.org>
> CC: Jon Hunter <jon-hunter(a)ti.com>
> CC: Ingo Molnar <mingo(a)elte.hu>
> CC: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
> CC: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
> CC: David Howells <dhowells(a)redhat.com>
> CC: Avi Kivity <avi(a)redhat.com>
> CC: "H. Peter Anvin" <hpa(a)zytor.com>
> CC: John Kacur <jkacur(a)redhat.com>
> CC: Alexander Shishkin <virtuoso(a)slind.org>
> CC: linux-kernel(a)vger.kernel.org
> ---
> include/linux/time.h | 7 ++
> init/Kconfig | 7 ++
> kernel/Makefile | 1 +
> kernel/time.c | 11 +++-
> kernel/time_notify.c | 158 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 182 insertions(+), 2 deletions(-)
> create mode 100644 kernel/time_notify.c
>
> diff --git a/include/linux/time.h b/include/linux/time.h
> index ea3559f..9fca62b 100644
> --- a/include/linux/time.h
> +++ b/include/linux/time.h
> @@ -237,6 +237,13 @@ static __always_inline void timespec_add_ns(struct timespec *a, u64 ns)
> a->tv_sec += __iter_div_u64_rem(a->tv_nsec + ns, NSEC_PER_SEC, &ns);
> a->tv_nsec = ns;
> }
> +
> +#ifdef CONFIG_TIME_NOTIFY
> +void time_notify_all(void);
> +#else
> +#define time_notify_all() do {} while (0)
> +#endif
> +
> #endif /* __KERNEL__ */
>
> #define NFDBITS __NFDBITS
> diff --git a/init/Kconfig b/init/Kconfig
> index 5cff9a9..f7271f8 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -976,6 +976,13 @@ config PERF_USE_VMALLOC
> help
> See tools/perf/design.txt for details
>
> +config TIME_NOTIFY
> + bool
> + depends on EVENTFD
> + help
> + Enable time change notification events to userspace via
> + eventfd.
> +

Do we really need config option? I think better just use
CONFIG_EVENTFD.

linux-api(a)vger.kernel.org added to CC list.

--
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 4 Aug 2010 11:50
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?

> userspace. Userspace always can check eventfd counter and understand who
> touch time based on its own activity.

That's another way to approach this, yes. But I can think of scenarios when
this will complicate userspace implementation. This generally means that the
"time monitor" application will have to increment some internal counter every
time it calls settimeofday() and friends. And when some library that it links
against starts calling one of those functions behind the scenes, it will
become trickier.

It is also true that you can never be too good to userspace.

> > Similar mechanism can also be used for signalling other (all?) system calls
> > made by certain (all?) processes without resorting to ptrace (which won't
> > help if you don't know what processes you'd like to look after), given
> > proper permission checks etc.
> >
> > Signed-off-by: Alexander Shishkin <virtuoso(a)slind.org>
> > CC: Kirill A. Shutemov <kirill(a)shutemov.name>
> > CC: Thomas Gleixner <tglx(a)linutronix.de>
> > CC: John Stultz <johnstul(a)us.ibm.com>
> > CC: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
> > CC: Andrew Morton <akpm(a)linux-foundation.org>
> > CC: Jon Hunter <jon-hunter(a)ti.com>
> > CC: Ingo Molnar <mingo(a)elte.hu>
> > CC: Peter Zijlstra <a.p.zijlstra(a)chello.nl>
> > CC: "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>
> > CC: David Howells <dhowells(a)redhat.com>
> > CC: Avi Kivity <avi(a)redhat.com>
> > CC: "H. Peter Anvin" <hpa(a)zytor.com>
> > CC: John Kacur <jkacur(a)redhat.com>
> > CC: Alexander Shishkin <virtuoso(a)slind.org>
> > CC: linux-kernel(a)vger.kernel.org
> > ---
> > include/linux/time.h | 7 ++
> > init/Kconfig | 7 ++
> > kernel/Makefile | 1 +
> > kernel/time.c | 11 +++-
> > kernel/time_notify.c | 158 ++++++++++++++++++++++++++++++++++++++++++++++++++
> > 5 files changed, 182 insertions(+), 2 deletions(-)
> > create mode 100644 kernel/time_notify.c
> >
> > diff --git a/include/linux/time.h b/include/linux/time.h
> > index ea3559f..9fca62b 100644
> > --- a/include/linux/time.h
> > +++ b/include/linux/time.h
> > @@ -237,6 +237,13 @@ static __always_inline void timespec_add_ns(struct timespec *a, u64 ns)
> > a->tv_sec += __iter_div_u64_rem(a->tv_nsec + ns, NSEC_PER_SEC, &ns);
> > a->tv_nsec = ns;
> > }
> > +
> > +#ifdef CONFIG_TIME_NOTIFY
> > +void time_notify_all(void);
> > +#else
> > +#define time_notify_all() do {} while (0)
> > +#endif
> > +
> > #endif /* __KERNEL__ */
> >
> > #define NFDBITS __NFDBITS
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 5cff9a9..f7271f8 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -976,6 +976,13 @@ config PERF_USE_VMALLOC
> > help
> > See tools/perf/design.txt for details
> >
> > +config TIME_NOTIFY
> > + bool
> > + depends on EVENTFD
> > + help
> > + Enable time change notification events to userspace via
> > + eventfd.
> > +
>
> Do we really need config option? I think better just use
> CONFIG_EVENTFD.

This is quite obscure. If anything, it's better to get rid of CONFIG_EVENTFD
and always unconditionally compile it in, while this functionality (time_notify)
may well be optional.

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: john stultz on 4 Aug 2010 12:00
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.

Doing some of my own googling, I see Apple added such a notification
method, which suggests there are apps that want this.
http://stackoverflow.com/questions/690326/how-can-i-get-notified-of-a-system-time-change-in-my-cocoa-application

But it doesn't give any specific examples either.

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: Alexander Shishkin on 4 Aug 2010 12:00
On Wed, Aug 04, 2010 at 02:54:12 +0200, Bastien ROUCARIES wrote:
> On Wed, Aug 4, 2010 at 2:48 PM, Alexander Shishkin <virtuoso(a)slind.org> 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.
>
> Why not implementing somtehing like http://lwn.net/Articles/323658/ a
> la plan 9 with a poll callback ?

Thanks for pointing this out, I'll investigate this approach.

> It will be plan9 compatible and so unix

I don't think that plan9 == unix statement is broadly correct, but I don't
know enough on the topic yet.

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/
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: linux-next: build failure after merge of the final tree (nfs tree related)
Next: [GIT] kbuild: packaging