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) 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 along with notification options 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 to 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.

Signed-off-by: Alexander Shishkin <virtuoso@slind.org>
CC: Kirill A. Shutemov <kirill@shutemov.name>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: John Stultz <johnstul@us.ibm.com>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Jon Hunter <jon-hunter@ti.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: David Howells <dhowells@redhat.com>
CC: Avi Kivity <avi@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: John Kacur <jkacur@redhat.com>
CC: Alexander Shishkin <virtuoso@slind.org>
CC: Chris Friesen <chris.friesen@genband.com>
CC: Kay Sievers <kay.sievers@vrfy.org>
CC: Greg KH <gregkh@suse.de>
CC: linux-kernel@vger.kernel.org
---
 ...
[ message continues ]

Really?  You obviously haven't added new Kconfig options to the kernel

Are you sure this is correct?

thanks,

greg k-h
--

[ message continues ]

On Wed, 18 Aug 2010 16:55:39 +0300

The requirements sound a bit fluffy to me.

Any time-displaying application will find out the new time next time
it reads the time.  So afaict this is only really useful for clock
applets which display once per minute, so they will show the new time
promptly after the time was altered, yes?  Is that really worth adding

hm.  Why?  What are you thinking of here, specifically?

Also... what's the story with kernel-NTP updates?
--

[ message continues ]

Actually a much more significant use case was given for the "civil
periodic" type events: something that wants to happen "every day at
noon", for example.  The logical thing of sleeping until the next noon
breaks if the walltime clock is changed.  As such, things like cron have
to resort to wake up once a minute just to assure themselves that they
have nothing to do.  This is inefficient, especially for battery-powered
devices.

Applications which display time aren't really as much affected, since
they generaly wake up every minute or every second anyway.

	-hpa
--

[ message continues ]

On Wed, 18 Aug 2010 16:43:48 -0700

OK.

Such applications might be better served via a wake-me-at-this-time
syscall instead of a sleep-me-for-this-long syscall.  Although such a
thing is less general.



Is sysfs the right interface for this thing?  Bear in mind that

why not

		sys_time_notify(efd, 1, 0, 1, 1);

?
--

[ message continues ]

Yeah, that would be much better than a sysfs file, this is abusing the
sysfs interface quite a lot.

thanks,

greg k-h
--

[ message continues ]

(time_change_notify would be a better syscall name).


--

[ message continues ]

Hm, ok. I used to think that adding new syscalls was discouraged, though.

Regards,
--
Alex
--

[ message continues ]

Do you really think, that increasing number of syscalls is better then
fs-based interfaces?

-- 
 Kirill A. Shutemov
--

[ message continues ]

Not necessarily, but adding such, and from the outside scope 'random
stuff', to /sys/kernel/ is really not the way to do such things.

It seems to be new dumping ground for things that don't have an
obvious home, and since proc is out of fashion. :)

Can't timerfd be used, or extended in some way? It really sounds like
the place this should happen.

Kay
--

[ message continues ]

As you are pretty much creating a new syscall here anyway, there is no
problem with making it a real one, right?  That way you can properly
handle the user/kernel documentation and persistance over time (i.e. you
can't change it.)

So yes, a syscall would be better, especially as this does not exactly
fit into the model of sysfs, right?

thanks,

greg k-h
--

[ message continues ]

I think Linux has too many syscalls. Significant part these interfaces

On the other, hand properly designed fs-based interface requires less
modification of userspeace to use it. Acctually, you can use most of
fs-based intefaces directly from shell. No need in libc modifications and
utilities to use it from shell or other script language.

Yes, sysfs is not the best place for it, but...

-- 
 Kirill A. Shutemov
--

[ message continues ]

What is the difference between a syscall and a filesystem interface?
They are both things that we can not change in the future and need to be
preserved and documented.


You just answered your own question.  Please don't make it in sysfs,
make it a syscall as it does not fit into sysfs.

thanks,

greg "constantly fighting to keep /sys/ from being like /proc/" k-h
--

[ message continues ]

Hmm, how about a syscallfs? :)

Regards,
--
Alex
--

[ message continues ]

And then there is the /dev/time proposal from Plan9:

  http://lkml.org/lkml/2009/3/11/363

Their proposal was to add a poll() method to the device which would wake
on every change in time.
--

[ message continues ]

Not for repeating events like cron needs.

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
--

[ message continues ]

No. I'll try to summarize all the things that have been said about the
use cases for this functionality earlier in the followup version so as

I haven't seen any poll-related code there, but it looks like the interface
which duplicates existing functionality for no gain.

It would be nice if they did some work on replacing {get,set}timeofday()
with read()s/write()s in glibc etc. But as of now this /dev/time looks quite
a pointless thing to have.

Regards,
--
Alex
--

[ message continues ]

There are other users of this functionality.  We have an emulator
running on top of linux which in turn runs code originally intended for
another OS.  It cares about walltime, so it wants to know ASAP if the
linux system time changes.

We've actually been carrying an internal patch doing something like this
for years now...never pushed it to mainline since we didn't think anyone
else would be interested.

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
--

[ message continues ]

Hey Alexander, 
	Glad to see this work continue! One thing did strike me as odd in
reading over this: Does adjtimex really make sense to trigger a
notification?  Its not actually changing the time, but alters the freq
that time runs. This freq adjustment is transparent to applications or
timers (unlike something like settimeofday).  So I'm not sure I see why
it is included here.

What use case did you have in mind for it?

thanks
-john


--

[ message continues ]