[lkml]   [2010]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] posix clocks: introduce a syscall for clock tuning.
    On Fri, 3 Sep 2010, Richard Cochran wrote:

    This patch needs to be split in pieces. The syscall change is totally
    unrelated to the dynamic clock id creation. Though I do not like
    either of them. :)

    > A new syscall is introduced that allows tuning of a POSIX clock. The
    > syscall is implemented for four architectures: arm, blackfin, powerpc,
    > and x86.
    > The new syscall, clock_adjtime, takes two parameters, the clock ID,
    > and a pointer to a struct timex. The semantics of the timex struct
    > have been expanded by one additional mode flag, which allows an
    > absolute offset correction. When specificied, the clock offset is
    > immediately corrected by skipping to the new time value.

    And why do we need a separate syscall for this?

    > In addition, the POSIX clock code has been augmented to offer a
    > dynamic clock creation method. Instead of registering a hard
    > coded clock ID, modules may call create_posix_clock(), which
    > returns a new clock ID.

    This has been discussed for years and I still fail to see the
    requirement for this. The only result is that it allows folks to
    create their special purpose clock stuff and keep it out of tree
    instead of fixing the problems they have with the existing clock
    infrastructure in the kernel.

    As far as I understood from the previous discussions, the final goal
    is to provide PTP support, right?

    But what I see is an approach which tries to implement disconnected
    special purpose clocks which have the ability to be adjusted
    independently. What's the purpose of this ? Why can't we just use the
    existing clocks and make PTP work on them ?

    I know that lots of embedded folks think that they need their special
    timers and extra magic to make stuff work, but that's the wrong

    What's wrong with the existing clocks? Nothing, except that we have no
    way to sync CLOCK_MONOTONIC across several machines. And that's what
    you really want if you try to do distributed control and data
    acquisition stuff.

    That's a single CLOCK_MONOTONIC_GLOBAL and not a bunch of completely
    disconnected clock implementations with random clock ids and random
    feature sets.

    Thoughts ?


     \ /
      Last update: 2010-09-09 12:51    [W:0.021 / U:308.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site