[PATCH 0/8] NTP updates - Kernel

This is a discussion on [PATCH 0/8] NTP updates - Kernel ; On Sat, 15 Mar 2008 04:18:39 +0100 (CET) Roman Zippel wrote: > Hi, > > On Fri, 14 Mar 2008, john stultz wrote: > > > Instead of exporting the clocksource making it global, could you use a > > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: [PATCH 0/8] NTP updates

  1. Re: [PATCH 8/8] handle leap second via timer

    On Sat, 15 Mar 2008 04:18:39 +0100 (CET)
    Roman Zippel wrote:

    > Hi,
    >
    > On Fri, 14 Mar 2008, john stultz wrote:
    >
    > > Instead of exporting the clocksource making it global, could you use a
    > > timekeeping_insert/remove_second() style interface?

    >
    > Sounds good.
    >


    It sounds like a few updates are in the pipeline, but I merged this series
    as-is into -mm.

    I'll normally push ntp changes through Thomas's git-hrt tree, however this
    patch series has dependencies upon at least

    introduce-explicit-signed-unsigned-64bit-divide.patch
    convert-a-few-do_div-user.patch
    rename-div64_64-to-div64_u64.patch
    rename-div64_64-to-div64_u64-mm.patch
    remove-div_long_long_rem.patch

    so they can't go into git-hrt immediately.

    The idealised algorithm is

    - 2.6.26 opens
    - Thomas merges git-hrt
    - I merge the above patches
    - I then send these ntp patches to Thomas
    - He merges them into git-hrt
    - He does another git-hrt -> Linus merge

    And that's all OK, but various lags might cause us to miss the merge
    window, as I merge the -mm stuff last, and some git-tree maintainers are
    dawdlers.

    So if Thomas wants to ack these I can merge them directly late in the
    2.6.26 merge window.

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

  2. Re: [PATCH 7/8] Remove current_tick_length()


    On Sat, 2008-03-15 at 18:14 +0100, Roman Zippel wrote:
    > Hi,
    >
    > On Sat, 15 Mar 2008, Ray Lee wrote:
    >
    > > Then make the original function an inline. With -O2 it should compile
    > > to exactly the same thing.

    >
    > This would also defeat John's intention of keeping the value static.


    Well, don't mistake me for being fanatical about it. Having the values
    be static is cleaner, but if its a real performance issue, then clearly
    performance wins.

    I do like Ray's suggestion, and think using the inline'd function is
    preferred to the raw variable, as it better establishes through use if
    nothing else, the read-only nature of the value outside of ntp.

    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/

  3. Re: [PATCH 8/8] handle leap second via timer

    On Mon, 17 Mar 2008, Andrew Morton wrote:
    > It sounds like a few updates are in the pipeline, but I merged this series
    > as-is into -mm.
    >
    > I'll normally push ntp changes through Thomas's git-hrt tree, however this
    > patch series has dependencies upon at least
    >
    > introduce-explicit-signed-unsigned-64bit-divide.patch
    > convert-a-few-do_div-user.patch
    > rename-div64_64-to-div64_u64.patch
    > rename-div64_64-to-div64_u64-mm.patch
    > remove-div_long_long_rem.patch
    >
    > so they can't go into git-hrt immediately.
    >
    > The idealised algorithm is
    >
    > - 2.6.26 opens
    > - Thomas merges git-hrt
    > - I merge the above patches
    > - I then send these ntp patches to Thomas
    > - He merges them into git-hrt
    > - He does another git-hrt -> Linus merge
    >
    > And that's all OK, but various lags might cause us to miss the merge
    > window, as I merge the -mm stuff last, and some git-tree maintainers are
    > dawdlers.




    > So if Thomas wants to ack these I can merge them directly late in the
    > 2.6.26 merge window.


    Fine for me either way.

    Thanks,

    tglx

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

  4. Re: [PATCH 7/8] Remove current_tick_length()

    Hi,

    On Tuesday 18. March 2008, john stultz wrote:

    > On Sat, 2008-03-15 at 18:14 +0100, Roman Zippel wrote:
    > > Hi,
    > >
    > > On Sat, 15 Mar 2008, Ray Lee wrote:
    > > > Then make the original function an inline. With -O2 it should compile
    > > > to exactly the same thing.

    > >
    > > This would also defeat John's intention of keeping the value static.

    >
    > Well, don't mistake me for being fanatical about it. Having the values
    > be static is cleaner, but if its a real performance issue, then clearly
    > performance wins.


    There are two aspects, such functions tend to generate slightly larger and
    slower code.

    > I do like Ray's suggestion, and think using the inline'd function is
    > preferred to the raw variable, as it better establishes through use if
    > nothing else, the read-only nature of the value outside of ntp.


    In other languages one would use private or protected for this, but we don't
    have this. I'm not too fond of an inline function, as it would mark it as
    some kind of public API, which it isn't. It's just an internal value used by
    the timekeeping code, which happens to be needed by a few source files. If
    you want to make a little more private, it would be better to move it to
    header under kernel/time/.

    bye, Roman
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2