On Fri, 2009-02-27 at 13:23 +0100, Karel Zak wrote:
> On Sat, Feb 14, 2009 at 12:12:54PM +0000, Scott James Remnant wrote:
> > +This is an alternate option to
> > +.B \-\-hctosys
> > +that does not read the hardware clock, and may be used in system startup
> > +scripts for recent 2.6 kernels where you know the System Time contains
> > +the Hardware Clock time. You must specify either
> ^^^^^^^^^^^^^^^^^^^^
> > +.B \-\-utc
> > +or
> > +.B \-\-localtime
> > +to indicate whether an adjustment needs to be made.
>
> Is it really good idea to require the --{utc,localtime} option when
> we have all necessary information in /etc/adjtime?
>
I did it that way simply because where we call hwclock, the root
filesystem is always read-only (both on startup and shutdown) so we
don't use /etc/adjtime at all.
I guess it makes sense to make that more flexible.
Should I rework the patch to do this?
> I think it should be optional like for the others hwclock operations.
> IMHO it's really bad idea to hardcode --{utc,localtime} to udev rules.
>
In our udev rules, we source a configuration file set by the installer
(the same /etc/default/rcS used by Debian).
> > +static int
> > +set_system_clock_timezone(const bool testing) {
>
> Here we duplicate a lot of code from set_system_clock(), right? :-)
>
It's similar in spirit, but localtime() is used in the exact opposite
way - to find out the difference and then apply it in the other
direction.
I also get the time again to keep the ns jump as small as possible.
> > + } else if (systz) {
> > + if (!universal) {
> > + rc = set_system_clock_timezone(testing);
> > + if (rc) {
> > + printf(_("Unable to set system clock.\n"));
>
> "Unable to set system timezone" ?
>
Possibly, though this does also reset the system clock as well.
Scott
--
Scott James Remnant
scott@xxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
