Re: [PATCH 0/2] [RFC] posix clock tuning

[Christoph Lameter]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/