lkml.org 
[lkml]   [2010]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
    From
    On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran
    <richardcochran@gmail.com> wrote:
    > This patch adds an infrastructure for hardware clocks that implement
    > IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
    > registration method to particular hardware clock drivers. Each clock is
    > exposed to user space as a character device with ioctls that allow tuning
    > of the PTP clock.
    >
    > Signed-off-by: Richard Cochran <richard.cochran@omicron.at>

    Hey Richard!
    Its very cool to see this work on lkml! I'm excited to see more
    work done on ptp. We had a short private thread discussion earlier (I
    got busy and never replied to your last message, my apologies!), but I
    wanted to bring up the concerns I have here as well.

    A few comments below....

    > +** PTP user space API
    > +
    > +   The class driver creates a character device for each registered PTP
    > +   clock. User space programs may control the clock using standardized
    > +   ioctls. A program may query, enable, configure, and disable the
    > +   ancillary clock features. User space can receive time stamped
    > +   events via blocking read() and poll(). One shot and periodic
    > +   signals may be configured via an ioctl API with semantics similar
    > +   to the POSIX timer_settime() system call.

    As I mentioned earlier, I'm not a huge fan of the char device
    interface for abstracted PTP clocks.
    If it was just the direct hardware access, similar to RTC, which user
    apps then use as a timesource, I'd not have much of a problem. But as
    I mentioned in an earlier private mail, the abstraction level concerns
    me.

    1) The driver-like model exposes a char dev for each clock, which
    allows for poorly-written userland applications to hit portability
    issues (ie: /dev/hpet vs /dev/rtc). Granted this isn't a huge flaw,
    but good APIs should be hard to get wrong.

    2) As Arnd already mentioned, the chardev interface seems to duplicate
    the clock_gettime/settime() and adjtimex() interfaces.

    3) I'm not sure I see the benefit of being able to have multiple
    frequency corrected time domains. In other words, what benefit would
    you get from adjusting a PTP clock's frequency instead of just
    adjusting the system's time freq? Having the PTP time as a reference
    to correct the system time seems reasonable, but I'm not sure I see
    why userland would want to adjust the PTP clock's freq.

    thanks
    -john
    --
    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/

    \
     
     \ /
      Last update: 2010-08-16 21:27    [W:4.083 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site