Messages in this thread | | | Subject | Re: [PATCHv6 0/7] system time changes notification | From | john stultz <> | Date | Thu, 11 Nov 2010 14:36:34 -0800 |
| |
On Thu, 2010-11-11 at 17:11 -0500, Kyle Moffett wrote: > On Thu, Nov 11, 2010 at 16:16, Thomas Gleixner <tglx@linutronix.de> wrote: > > The notification itself is pointless unless your application is > > dealing with timers which need to be adjusted the one way or the > > other. > > > > That said, I'm still not convinced that this usecase justifies a new > > systemcall. > > > > 1) We can make timers wake up when a clock change happens
I think this seems like the most interesting solution.
However we may need some sort of special flag, as I don't think many timers are expecting to fire before the specified time, so you'd likely break regular applications if all timers woke up on clock changes.
> > 2) Can't we use existing notification stuff like uevents or such ? > > What about maybe adding device nodes for various kinds of "clock" > devices? You could then do: > > #define CLOCK_FD 0x80000000 > fd = open("/dev/clock/realtime", O_RDWR); > poll(fd); > clock_gettime(CLOCK_FD|fd, &ts);
Ehh.. I'm not a huge fan of creating dynamic ids for what are static clocksources (REALTIME, MONOTONIC, etc).
That said...
> [...] > > This would also enable the folks who want to support things like PHY > hardware clocks (for very-low-latency ethernet timestamping). It > would resolve the enumeration problem; instead of 0, 1, 2, ... as > constants, they would show up in sysfs and be open()able. Ideally you > would be able to set up ntpd to slew the "realtime" clock by following > a particular hardware clock, or vice versa.
This is very similar in spirit to what's being done by Richard Cochran's dynamic clock devices code: http://lwn.net/Articles/413332/
thanks -john
| |