[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100806071100.GF28519@shisha.kicks-ass.net>
Date: Fri, 6 Aug 2010 10:11:00 +0300
From: Alexander Shishkin <virtuoso@...nd.org>
To: Kay Sievers <kay.sievers@...y.org>
Cc: Greg KH <gregkh@...e.de>, john stultz <johnstul@...ibm.com>,
lkml@...r.kernel.org, "Kirill A. Shutemov" <kirill@...temov.name>,
Thomas Gleixner <tglx@...utronix.de>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jon Hunter <jon-hunter@...com>, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
David Howells <dhowells@...hat.com>,
Avi Kivity <avi@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
John Kacur <jkacur@...hat.com>, linux-kernel@...r.kernel.org,
Alexander Shishkin <virtuoso@...nd.org>
Subject: Re: [PATCH] [RFC] notify userspace about time changes
On Fri, Aug 06, 2010 at 12:22:27 +0200, Kay Sievers wrote:
> On Thu, Aug 5, 2010 at 23:38, Greg KH <gregkh@...e.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@...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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists