[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/28] Rework of the PTP support series core code
On Tue, Feb 01, 2011 at 01:50:55PM -0000, Thomas Gleixner wrote:
> This is a rework of Richards PTP support series core code. The PTP
> driver patches are unchanged and not included in this series.
> The reason for this rework is that I got scared when reviewing:
> [PATCH V10 09/15] posix clocks: cleanup the CLOCK_DISPTACH macro
> The patch is really too large and the risk of wreckage too high. So
> instead of whipping Richard through another round I reworked the
> series in the following way:
> 1) Split the CLOCK_DISPATCH cleanup in fine grained steps.
> That allowed further cleanups and got rid of 200 lines of code and
> made a lot of functions static.
> It also fixes subtle changes to the error return codes which happened
> in the large all in one overhaul (EINVAL vs. ENOTSUP).
> 2) Move the patches which add new functionality after the cleanup.
> It does not make sense to add new functionality into the old scheme
> first and then clean it up.
> Richard, can you please run that through your testing ? The PTP
> drivers apply on top of that.

i am a bit puzzled how a software ptp clock would fit into this
framework. for some avb use-cases we could get away with a ptp clock
thats only accurate to a few 100us.

from a few quick glances it seems, that if userspace is able to create a
ptp clock driven by normal timers and the kernel allows for timestamping
packets using that clock, a modified ptpd could do the trick.

i am not sure, how much of this should be happening in userspace though.

torben Hohn

 \ /
  Last update: 2011-03-01 16:41    [W:0.325 / U:2.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site