From: JWP <elseifthen@gmx.com>
To: "Noé RUBINSTEIN" <nrubinstein@aldebaran.com>
Cc: util-linux <util-linux@vger.kernel.org>
Subject: Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
Date: Thu, 09 Oct 2014 07:15:39 -0400 [thread overview]
Message-ID: <54366E5B.7010302@gmx.com> (raw)
In-Reply-To: <CAOJKDv+97LPMBJARpUSJ0en9NNDDuymSBWi_mJ+302AOSCdWaQ@mail.gmail.com>
Hello Noé,
I recalled the first set of patches from 14/09/14 titled
'[PATCH 1/2] hwclock: hctosys drift compensation' and
'[PATCH 2/2] hwclock: hctosys drift compensation man page'
Do not use those.
Use only the 1/7 ~ 7/7 patch set as it supersedes the first.
Sorry for the confusion.
On 10/09/2014 04:51 AM, Noé RUBINSTEIN wrote:
> Hi J,
>
> I tried appplying your patches and got into some problems:
>> Applying: hwclock: hctosys drift compensation II
>> error: patch failed: sys-utils/hwclock.c:807
>> error: sys-utils/hwclock.c: patch does not apply
>
> I tried that both upon origin/master and upon fb2ba06, which you seem
> to have based your first patch on.
>
> Here's the list of patches I was trying to apply:
>> [PATCH 1/2] hwclock: hctosys drift compensation
>> [PATCH 2/2] hwclock: hctosys drift compensation man page
>> [PATCH 1/7] hwclock: hctosys drift compensation II
>> [PATCH 2/7] hwclock: hctosys drift compensation II COMMENTS
>> [PATCH 3/7] hwclock: hctosys drift compensation II MAN
>> [PATCH 4/7] hwclock: persistent_clock_is_local
>> [PATCH 5/7] hwclock: persistent_clock_is_local MAN
>> [PATCH 6/7] hwclock: Add --update option
>> [PATCH 7/7] hwclock: Add --update option MAN
>
> Did I overlook a patch somewhere?
>
>
> 2014-10-07 17:50 GMT+02:00 JWP <elseifthen@gmx.com>:
>>
>> On 10/07/2014 08:48 AM, Noé RUBINSTEIN wrote:
>>>> Sure, hwclock already has the ability to track the offset between the
>>>> Hardware Clock and the System Clock(which presumably is the 'correct' time).
>>> ...but this information is recorded only when setting the hardware
>>> clock, which is impossible on some (arguably buggy) targets.
>>
>> Are you sure that drift factor (re)calculation does not happen if
>> writing the Hardware Clock fails? I just had a quick look at the
>> code and it seem that we do not test to see if write fails. So
>> (re)calculation might work as is?
>
next prev parent reply other threads:[~2014-10-09 11:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 9:15 [RFC PATCH] hwclock: --offset: Use offset instead of writing clock Noé Rubinstein
2014-10-07 11:28 ` JWP
2014-10-07 11:52 ` Noé RUBINSTEIN
2014-10-07 12:13 ` JWP
2014-10-07 12:48 ` Noé RUBINSTEIN
2014-10-07 15:19 ` JWP
2014-10-07 15:50 ` JWP
2014-10-09 8:51 ` Noé RUBINSTEIN
2014-10-09 11:15 ` JWP [this message]
2014-10-09 15:05 ` Noé RUBINSTEIN
2014-10-10 0:11 ` JWP
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54366E5B.7010302@gmx.com \
--to=elseifthen@gmx.com \
--cc=nrubinstein@aldebaran.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.