On 11/03/2014 04:15 PM, Benno Schulenberg wrote: > Well, there are several problems with your (and also Karels) version > of the text. First, "automatically". The word suggests to me that > there is/was a way to do this unautomatically, that is: by the use of > an option. But is was never possible to make hwclock set the System > Clock to a drift-compensated time without touching the Hardware Clock > nor the adjtime file. Second, "compensates time [...] to account for". > The expression in English is " to compensate something /for/ a deviance" -- > there should be no "to account". But the interposing of "read from the > Hardware Clock" makes the use of this expression difficult to grasp. > So it's better to rewrite the whole thing. Third, a "the" is needed > before "time". Fourth, the "This functionality" referring to --adjust > no longer being necessary during boot is awkward; it's second word > can simply de dropped. I do not disagree with you here. I did not want to be heavy handed when editing Karel's words, because it is his project and I am new here. I only wanted to make clear to the reader that the Hardware Clock itself was not being altered. > > So... my suggestion: > > "Since v2.26 hwclock --hctosys does a better job at setting the System Clock: > it no longer simply copies the time from the Hardware Clock to the System Clock, > but it reads the Hardware Clock, applies a compensation for the systematic drift > to this read time, and sets the System Clock to the resulting time. Thus it is > no longer necessary to run hwclock --adjust before doing hwclock --hctosys, and > therefore hwclock can be used very early on in the boot process when the root > filesystem is still read-only." > > Any amendments? Nope, that seems quite complete Benno! -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
