All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
@ 2014-10-07  9:15 Noé Rubinstein
  2014-10-07 11:28 ` JWP
  0 siblings, 1 reply; 11+ messages in thread
From: Noé Rubinstein @ 2014-10-07  9:15 UTC (permalink / raw)
  To: util-linux; +Cc: Noé Rubinstein

From: Noé Rubinstein <noe.rubinstein@gmail.com>

This option is useful for systems that have a working hardware clock, but do
not provide a way to write to it. Instead of setting the hardware clock, write
the difference between hardware and system clock to a file; when getting the
hardware clock, add the offset from this file to obtain the correct time.

I have not checked how well this interacts with the adjtime mechanism, so
this is an RFC patch.
---
 sys-utils/hwclock.8.in |  6 ++++
 sys-utils/hwclock.c    | 88 ++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/sys-utils/hwclock.8.in b/sys-utils/hwclock.8.in
index b11b45c..63fabda 100644
--- a/sys-utils/hwclock.8.in
+++ b/sys-utils/hwclock.8.in
@@ -113,6 +113,12 @@ not reset.
 .BR \-w , \ \-\-systohc
 Set the Hardware Clock to the current System Time.
 .TP
+.BR \-\-offset[=filename]
+This option is useful for systems that have a working hardware clock, but do
+not provide a way to write to it. Instead of setting the hardware clock, write
+the difference between hardware and system clock to a file; when getting the
+hardware clock, add the offset from this file to obtain the correct time.
+.TP
 .BR \-V , \ \-\-version
 Display version information and exit.
 .TP
diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
index e780158..c7deab9 100644
--- a/sys-utils/hwclock.c
+++ b/sys-utils/hwclock.c
@@ -98,6 +98,7 @@ struct clock_ops *ur;
 #define MAX_DRIFT 2145.0
 
 const char *adj_file_name = NULL;
+const char *offset_file_name = NULL;
 
 struct adjtime {
 	/*
@@ -234,6 +235,35 @@ hw_clock_is_utc(const bool utc, const bool local_opt,
 	return ret;
 }
 
+static int read_offset(struct timeval *offset)
+{
+	FILE *f;
+	int rc;
+	f = fopen(offset_file_name, "r");
+	if (!f)
+		return -errno;
+
+	rc = fread(offset, sizeof(*offset), 1, f);
+	fclose(f);
+
+	return rc == 1 ? 0 : -EINVAL;
+}
+
+static int write_offset(struct timeval offset)
+{
+	FILE *f;
+	int rc;
+	f = fopen(offset_file_name, "w");
+	if (!f)
+		return -errno;
+
+	rc = fwrite(&offset, sizeof(offset), 1, f);
+	fclose(f);
+
+	return rc == 1 ? 0 : -EINVAL;
+}
+
+
 /*
  * Read the adjustment parameters out of the /etc/adjtime file.
  *
@@ -1290,6 +1320,8 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 	bool no_auth;
 	/* The time at which we read the Hardware Clock */
 	struct timeval read_time;
+	/* The offset between system time and hardware time */
+	struct timeval offset = {0};
 	/*
 	 * The Hardware Clock gives us a valid time, or at
 	 * least something close enough to fool mktime().
@@ -1320,6 +1352,11 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 		adjtime.dirty = FALSE;
 	}
 
+	if ((hctosys || show) && offset_file_name)
+	{
+		read_offset(&offset);
+	}
+
 	universal = hw_clock_is_utc(utc, local_opt, adjtime);
 
 	if ((set || systohc || adjust) &&
@@ -1328,7 +1365,8 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 		adjtime.dirty = TRUE;
 	}
 
-	if (show || adjust || hctosys || (!noadjfile && !systz && !predict)) {
+	if (show || adjust || hctosys || (!noadjfile && !systz && !predict) ||
+	    offset_file_name) {
 		/* data from HW-clock are required */
 		rc = synchronize_to_clock_tick();
 
@@ -1358,8 +1396,20 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 	}
 
 	if (show) {
-		display_time(hclock_valid, hclocktime,
+		display_time(hclock_valid, hclocktime + offset.tv_sec,
 			     time_diff(read_time, startup_time));
+	} else if (set && offset_file_name) {
+		if (!hclock_valid) {
+			printf(_("Hardware clock invalid, not writing offset.\n"));
+		} else {
+			offset.tv_sec = set_time - hclocktime;
+			rc = write_offset(offset);
+			if (rc) {
+				printf(_("Unable to write offset: %s."), strerror(-rc));
+				return rc;
+			}
+		}
+
 	} else if (set) {
 		set_hardware_clock_exact(set_time, startup_time,
 					 universal, testing);
@@ -1371,6 +1421,18 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 	} else if (adjust) {
 		do_adjustment(&adjtime, hclock_valid,
 			      hclocktime, read_time, universal, testing);
+	} else if (systohc && offset_file_name) {
+		if (!hclock_valid) {
+			printf(_("Hardware clock invalid, not writing offset.\n"));
+		} else {
+			gettimeofday(&offset, NULL);
+			offset.tv_sec -= hclocktime;
+			rc = write_offset(offset);
+			if (rc) {
+				printf(_("Unable to write offset: %s."), strerror(-rc));
+				return rc;
+			}
+		}
 	} else if (systohc) {
 		struct timeval nowtime, reftime;
 		/*
@@ -1390,6 +1452,17 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
 					    reftime.tv_sec,
 					    hclock_valid, hclocktime, (double)
 					    read_time.tv_usec / 1E6);
+	} else if (hctosys && offset_file_name) {
+		if (!hclock_valid) {
+			printf(_("Hardware clock invalid, not setting time.\n"));
+		} else {
+			offset.tv_sec += hclocktime;
+			rc = settimeofday(&offset, NULL);
+			if (rc) {
+				printf(_("Unable to set system clock.\n"));
+				return rc;
+			}
+		}
 	} else if (hctosys) {
 		rc = set_system_clock(hclock_valid, hclocktime, testing);
 		if (rc) {
@@ -1547,6 +1620,7 @@ static void out_version(void)
 	printf(UTIL_LINUX_VERSION);
 }
 
+#define DEFAULT_OFFSET_FILE "/etc/time_offset"
 /*
  * usage - Output (error and) usage information
  *
@@ -1577,6 +1651,10 @@ static void usage(const char *fmt, ...)
 		"     --adjust         adjust the RTC to account for systematic drift since\n"
 		"                        the clock was last set or adjusted\n"), usageto);
 	fputs(_(" -c, --compare        periodically compare the system clock with the CMOS clock\n"), usageto);
+	fprintf(usageto,
+	      _("     --offset [file]  instead of setting the clock, write an offset to file.\n"
+	        "                      when reading the time, add this offset to the hardware time.\n"
+		"                         (default: %s)\n"), DEFAULT_OFFSET_FILE);
 #ifdef __linux__
 	fputs(_("     --getepoch       print out the kernel's hardware clock epoch value\n"
 		"     --setepoch       set the kernel's hardware clock epoch value to the \n"
@@ -1653,6 +1731,7 @@ int main(int argc, char **argv)
 	/* Long only options. */
 	enum {
 		OPT_ADJFILE = CHAR_MAX + 1,
+		OPT_OFFSET,
 		OPT_BADYEAR,
 		OPT_DATE,
 		OPT_DIRECTISA,
@@ -1698,6 +1777,7 @@ int main(int argc, char **argv)
 		{"test",	0, 0, OPT_TEST},
 		{"date",	1, 0, OPT_DATE},
 		{"epoch",	1, 0, OPT_EPOCH},
+		{"offset",	2, 0, OPT_OFFSET},
 #ifdef __linux__
 		{"rtc",		1, 0, 'f'},
 #endif
@@ -1837,6 +1917,10 @@ int main(int argc, char **argv)
 		case OPT_PREDICT_HC:
 			predict = TRUE;		/* --predict-hc */
 			break;
+		case OPT_OFFSET:
+			offset_file_name =	/* --offset */
+				optarg ? optarg : DEFAULT_OFFSET_FILE;
+			break;
 #ifdef __linux__
 		case 'f':
 			rtc_dev_name = optarg;	/* --rtc */
-- 
2.1.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  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
  0 siblings, 1 reply; 11+ messages in thread
From: JWP @ 2014-10-07 11:28 UTC (permalink / raw)
  To: Noé Rubinstein, util-linux; +Cc: Noé Rubinstein

Hello Noé,
 I just submitted a patch on 14-09-27 that adds this functionality
without creating a new state file.

On 10/07/2014 05:15 AM, Noé Rubinstein wrote:
> From: Noé Rubinstein <noe.rubinstein@gmail.com>
> 
> This option is useful for systems that have a working hardware clock, but do
> not provide a way to write to it. Instead of setting the hardware clock, write
> the difference between hardware and system clock to a file; when getting the
> hardware clock, add the offset from this file to obtain the correct time.
> 
> I have not checked how well this interacts with the adjtime mechanism, so
> this is an RFC patch.
> ---
>  sys-utils/hwclock.8.in |  6 ++++
>  sys-utils/hwclock.c    | 88 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  2 files changed, 92 insertions(+), 2 deletions(-)
> 
> diff --git a/sys-utils/hwclock.8.in b/sys-utils/hwclock.8.in
> index b11b45c..63fabda 100644
> --- a/sys-utils/hwclock.8.in
> +++ b/sys-utils/hwclock.8.in
> @@ -113,6 +113,12 @@ not reset.
>  .BR \-w , \ \-\-systohc
>  Set the Hardware Clock to the current System Time.
>  .TP
> +.BR \-\-offset[=filename]
> +This option is useful for systems that have a working hardware clock, but do
> +not provide a way to write to it. Instead of setting the hardware clock, write
> +the difference between hardware and system clock to a file; when getting the
> +hardware clock, add the offset from this file to obtain the correct time.
> +.TP
>  .BR \-V , \ \-\-version
>  Display version information and exit.
>  .TP
> diff --git a/sys-utils/hwclock.c b/sys-utils/hwclock.c
> index e780158..c7deab9 100644
> --- a/sys-utils/hwclock.c
> +++ b/sys-utils/hwclock.c
> @@ -98,6 +98,7 @@ struct clock_ops *ur;
>  #define MAX_DRIFT 2145.0
>  
>  const char *adj_file_name = NULL;
> +const char *offset_file_name = NULL;
>  
>  struct adjtime {
>  	/*
> @@ -234,6 +235,35 @@ hw_clock_is_utc(const bool utc, const bool local_opt,
>  	return ret;
>  }
>  
> +static int read_offset(struct timeval *offset)
> +{
> +	FILE *f;
> +	int rc;
> +	f = fopen(offset_file_name, "r");
> +	if (!f)
> +		return -errno;
> +
> +	rc = fread(offset, sizeof(*offset), 1, f);
> +	fclose(f);
> +
> +	return rc == 1 ? 0 : -EINVAL;
> +}
> +
> +static int write_offset(struct timeval offset)
> +{
> +	FILE *f;
> +	int rc;
> +	f = fopen(offset_file_name, "w");
> +	if (!f)
> +		return -errno;
> +
> +	rc = fwrite(&offset, sizeof(offset), 1, f);
> +	fclose(f);
> +
> +	return rc == 1 ? 0 : -EINVAL;
> +}
> +
> +
>  /*
>   * Read the adjustment parameters out of the /etc/adjtime file.
>   *
> @@ -1290,6 +1320,8 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  	bool no_auth;
>  	/* The time at which we read the Hardware Clock */
>  	struct timeval read_time;
> +	/* The offset between system time and hardware time */
> +	struct timeval offset = {0};
>  	/*
>  	 * The Hardware Clock gives us a valid time, or at
>  	 * least something close enough to fool mktime().
> @@ -1320,6 +1352,11 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  		adjtime.dirty = FALSE;
>  	}
>  
> +	if ((hctosys || show) && offset_file_name)
> +	{
> +		read_offset(&offset);
> +	}
> +
>  	universal = hw_clock_is_utc(utc, local_opt, adjtime);
>  
>  	if ((set || systohc || adjust) &&
> @@ -1328,7 +1365,8 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  		adjtime.dirty = TRUE;
>  	}
>  
> -	if (show || adjust || hctosys || (!noadjfile && !systz && !predict)) {
> +	if (show || adjust || hctosys || (!noadjfile && !systz && !predict) ||
> +	    offset_file_name) {
>  		/* data from HW-clock are required */
>  		rc = synchronize_to_clock_tick();
>  
> @@ -1358,8 +1396,20 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  	}
>  
>  	if (show) {
> -		display_time(hclock_valid, hclocktime,
> +		display_time(hclock_valid, hclocktime + offset.tv_sec,
>  			     time_diff(read_time, startup_time));
> +	} else if (set && offset_file_name) {
> +		if (!hclock_valid) {
> +			printf(_("Hardware clock invalid, not writing offset.\n"));
> +		} else {
> +			offset.tv_sec = set_time - hclocktime;
> +			rc = write_offset(offset);
> +			if (rc) {
> +				printf(_("Unable to write offset: %s."), strerror(-rc));
> +				return rc;
> +			}
> +		}
> +
>  	} else if (set) {
>  		set_hardware_clock_exact(set_time, startup_time,
>  					 universal, testing);
> @@ -1371,6 +1421,18 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  	} else if (adjust) {
>  		do_adjustment(&adjtime, hclock_valid,
>  			      hclocktime, read_time, universal, testing);
> +	} else if (systohc && offset_file_name) {
> +		if (!hclock_valid) {
> +			printf(_("Hardware clock invalid, not writing offset.\n"));
> +		} else {
> +			gettimeofday(&offset, NULL);
> +			offset.tv_sec -= hclocktime;
> +			rc = write_offset(offset);
> +			if (rc) {
> +				printf(_("Unable to write offset: %s."), strerror(-rc));
> +				return rc;
> +			}
> +		}
>  	} else if (systohc) {
>  		struct timeval nowtime, reftime;
>  		/*
> @@ -1390,6 +1452,17 @@ manipulate_clock(const bool show, const bool adjust, const bool noadjfile,
>  					    reftime.tv_sec,
>  					    hclock_valid, hclocktime, (double)
>  					    read_time.tv_usec / 1E6);
> +	} else if (hctosys && offset_file_name) {
> +		if (!hclock_valid) {
> +			printf(_("Hardware clock invalid, not setting time.\n"));
> +		} else {
> +			offset.tv_sec += hclocktime;
> +			rc = settimeofday(&offset, NULL);
> +			if (rc) {
> +				printf(_("Unable to set system clock.\n"));
> +				return rc;
> +			}
> +		}
>  	} else if (hctosys) {
>  		rc = set_system_clock(hclock_valid, hclocktime, testing);
>  		if (rc) {
> @@ -1547,6 +1620,7 @@ static void out_version(void)
>  	printf(UTIL_LINUX_VERSION);
>  }
>  
> +#define DEFAULT_OFFSET_FILE "/etc/time_offset"
>  /*
>   * usage - Output (error and) usage information
>   *
> @@ -1577,6 +1651,10 @@ static void usage(const char *fmt, ...)
>  		"     --adjust         adjust the RTC to account for systematic drift since\n"
>  		"                        the clock was last set or adjusted\n"), usageto);
>  	fputs(_(" -c, --compare        periodically compare the system clock with the CMOS clock\n"), usageto);
> +	fprintf(usageto,
> +	      _("     --offset [file]  instead of setting the clock, write an offset to file.\n"
> +	        "                      when reading the time, add this offset to the hardware time.\n"
> +		"                         (default: %s)\n"), DEFAULT_OFFSET_FILE);
>  #ifdef __linux__
>  	fputs(_("     --getepoch       print out the kernel's hardware clock epoch value\n"
>  		"     --setepoch       set the kernel's hardware clock epoch value to the \n"
> @@ -1653,6 +1731,7 @@ int main(int argc, char **argv)
>  	/* Long only options. */
>  	enum {
>  		OPT_ADJFILE = CHAR_MAX + 1,
> +		OPT_OFFSET,
>  		OPT_BADYEAR,
>  		OPT_DATE,
>  		OPT_DIRECTISA,
> @@ -1698,6 +1777,7 @@ int main(int argc, char **argv)
>  		{"test",	0, 0, OPT_TEST},
>  		{"date",	1, 0, OPT_DATE},
>  		{"epoch",	1, 0, OPT_EPOCH},
> +		{"offset",	2, 0, OPT_OFFSET},
>  #ifdef __linux__
>  		{"rtc",		1, 0, 'f'},
>  #endif
> @@ -1837,6 +1917,10 @@ int main(int argc, char **argv)
>  		case OPT_PREDICT_HC:
>  			predict = TRUE;		/* --predict-hc */
>  			break;
> +		case OPT_OFFSET:
> +			offset_file_name =	/* --offset */
> +				optarg ? optarg : DEFAULT_OFFSET_FILE;
> +			break;
>  #ifdef __linux__
>  		case 'f':
>  			rtc_dev_name = optarg;	/* --rtc */
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-07 11:28 ` JWP
@ 2014-10-07 11:52   ` Noé RUBINSTEIN
  2014-10-07 12:13     ` JWP
  0 siblings, 1 reply; 11+ messages in thread
From: Noé RUBINSTEIN @ 2014-10-07 11:52 UTC (permalink / raw)
  To: JWP; +Cc: util-linux

Hi,

> I just submitted a patch on 14-09-27 that adds this functionality
> without creating a new state file.

Nice! I guess this is the patchset:
<http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/9918>

However I am not sure how those patches adds the functionality I am
looking for. Can you explain how you would use hwclock to get and set
the time without a write access to the hardware clock?

Regards,
Noé.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-07 11:52   ` Noé RUBINSTEIN
@ 2014-10-07 12:13     ` JWP
  2014-10-07 12:48       ` Noé RUBINSTEIN
  0 siblings, 1 reply; 11+ messages in thread
From: JWP @ 2014-10-07 12:13 UTC (permalink / raw)
  To: Noé RUBINSTEIN; +Cc: util-linux



On 10/07/2014 07:52 AM, Noé RUBINSTEIN wrote:
> Hi,
> 
>> I just submitted a patch on 14-09-27 that adds this functionality
>> without creating a new state file.
> 
> Nice! I guess this is the patchset:
> <http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/9918>
> 
> However I am not sure how those patches adds the functionality I am
> looking for. Can you explain how you would use hwclock to get and set
> the time without a write access to the hardware clock?

Sure, hwclock already has the ability to track the offset between the 
Hardware Clock and the System Clock(which presumably is the 'correct' time).
With my patch, hctosys will include the offset when setting the System 
Clock. Which is the functionality you want, right?





> 
> Regards,
> Noé.
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  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
  0 siblings, 2 replies; 11+ messages in thread
From: Noé RUBINSTEIN @ 2014-10-07 12:48 UTC (permalink / raw)
  To: JWP; +Cc: util-linux

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

> With my patch, hctosys will include the offset when setting the System
> Clock. Which is the functionality you want, right?
Nearly.

I guess in order for the use-case I want to be possible we would need
an option for --systohc/--set to modify the adjtime file, but not to
touch the hardware clock.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-07 12:48       ` Noé RUBINSTEIN
@ 2014-10-07 15:19         ` JWP
  2014-10-07 15:50         ` JWP
  1 sibling, 0 replies; 11+ messages in thread
From: JWP @ 2014-10-07 15:19 UTC (permalink / raw)
  To: Noé RUBINSTEIN; +Cc: util-linux



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.

I would think we should fix that. What hardware is it that hwclock cannot
set the Hardware Clock?

> 
>> With my patch, hctosys will include the offset when setting the System
>> Clock. Which is the functionality you want, right?
> Nearly.
> 
> I guess in order for the use-case I want to be possible we would need
> an option for --systohc/--set to modify the adjtime file, but not to
> touch the hardware clock.

Well, we could (re)calculate the drift factor even if setting the Hardware
Clock fails, or have an option to (re)calculate without setting the HW Clock.
I am willing to write such a patch if Mr. Zak approves.


> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  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
  1 sibling, 1 reply; 11+ messages in thread
From: JWP @ 2014-10-07 15:50 UTC (permalink / raw)
  To: Noé RUBINSTEIN; +Cc: util-linux


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?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-07 15:50         ` JWP
@ 2014-10-09  8:51           ` Noé RUBINSTEIN
  2014-10-09 11:15             ` JWP
  0 siblings, 1 reply; 11+ messages in thread
From: Noé RUBINSTEIN @ 2014-10-09  8:51 UTC (permalink / raw)
  To: JWP; +Cc: util-linux

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?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-09  8:51           ` Noé RUBINSTEIN
@ 2014-10-09 11:15             ` JWP
  2014-10-09 15:05               ` Noé RUBINSTEIN
  0 siblings, 1 reply; 11+ messages in thread
From: JWP @ 2014-10-09 11:15 UTC (permalink / raw)
  To: Noé RUBINSTEIN; +Cc: util-linux

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-09 11:15             ` JWP
@ 2014-10-09 15:05               ` Noé RUBINSTEIN
  2014-10-10  0:11                 ` JWP
  0 siblings, 1 reply; 11+ messages in thread
From: Noé RUBINSTEIN @ 2014-10-09 15:05 UTC (permalink / raw)
  To: JWP; +Cc: util-linux

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

It does not seem to work the obvious way:

> [root@localhost ~]# date
> Thu Oct  9 14:56:30 UTC 2014
> [root@localhost ~]# hwclock --systohc --update
> hwclock: ioctl(RTC_SET_TIME) to /dev/rtc to set the time failed.: Invalid argument
> [root@localhost ~]# hwclock --get
> Thu Jan  8 05:12:51 1970  .543449 seconds

I will try to look into it.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [RFC PATCH] hwclock: --offset: Use offset instead of writing clock
  2014-10-09 15:05               ` Noé RUBINSTEIN
@ 2014-10-10  0:11                 ` JWP
  0 siblings, 0 replies; 11+ messages in thread
From: JWP @ 2014-10-10  0:11 UTC (permalink / raw)
  To: Noé RUBINSTEIN; +Cc: util-linux



On 10/09/2014 11:05 AM, Noé RUBINSTEIN wrote:
>> 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?
> 
> It does not seem to work the obvious way:
> 
> [root@localhost ~]# date
> Thu Oct  9 14:56:30 UTC 2014
> [root@localhost ~]# hwclock --systohc --update
> hwclock: ioctl(RTC_SET_TIME) to /dev/rtc to set the time failed.: Invalid argument
> [root@localhost ~]# hwclock --get
> Thu Jan  8 05:12:51 1970  .543449 seconds

You cannot initialize the Hardware Clock at all? Not even through
the BIOS?  If the Hardware Clock cannot be set at all, then my
patch will not help you.  Sorry if I misunderstood.

What machine are you using?




^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-10-10  0:11 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2014-10-09 15:05               ` Noé RUBINSTEIN
2014-10-10  0:11                 ` JWP

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.