On Sun, 5 Sep 2010, Richard Cochran wrote: > Again, I meant "PTP hardware clocks." > > When I get some more time, I'll try to put together an executive > summary of PTP and of all the discussions that have taken place over > the last few months on linux-netdev and the lkml. I know PTP, I just dont know why you would need to extend the existing apis for support. Maybe you could just simply write a PTP clock driver? If you follow the way hpet is implemented then you dont even need a clock id. See drivers/char/hpet.c. I cannot imagine why someone would want to set PTP to a different time and speed (vs. realtime not the hardware configuration) than the standard clock. The API you proposed so far is not needed as far as I can tell. I really would like a PTP clock as soon as possible. Very very important for time sync via the network. Then there is CLOCK_SGI_CYCLE. Another hw clock that can be set and gotten already with the standard posix interface. See drivers/char/mmtimer.c. The main benefit from CLOCK_SGI_CYCLE is that you can set it manually (maybe you want an offset to realtime? But I do not know of any usecase for setting the clock) and that the clock can cause hardware IRQ events to cause timer timers in user space (would be great to know if PTP needs this?). The clock is also distributed in the local memory space of each node. Plus the clock device can be configured in some fashion (but then hpet also has some ioctls). I would not think that PTP needs any of this specialized functionality. John point about not wanting to proliferate different APIs and useless clock ids is valid. An intial implementation using hpet style stuff would be satisfactory and as far as I can tell would be rather trivial to do. Standardizing the ioctls between the different clock drivers would be useful so that they can all be controlled with some common API. But it would be great to first have a release of a clock_ptp listing all the needed ioctl so that we can see what the common subset is. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html