On Thu, 2010-11-11 at 17:11 -0500, Kyle Moffett wrote:
quoted text
> 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.


quoted text
> > 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...

quoted text
> [...]
> 
> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/