> Hi Ulrich.
>
> > maybe the problem running RTC in non-UTC time is known to you,
> > including its implications. Basically the kernel lacks two
> > things when booting:
>
> > 1) time zone
> > 2) Whether RTC runs UTC or local time
>
> Certainly on my setup, the kernel never even attempts to read the RTC
> itself and that's left to a userspace program (hwclock) that gets run
> from the boot scripts with the relevant parameters. The said program
> also makes use of a SymLink that tells it what the local timezone is,
> so has all the information needed to RE-initialise the system clock to
> match what the hardware clock claims is the case.
The user space utility concept has a problem: What will be the kernel
boot time, and what is the time when the filesystems are mounted or
checked? Also a use space utility may cause a time warp on every boot.
>
> > My solution would be:
>
> > 1) Add a kernel parameter like RTC=UTC|local
> > 2) Add a kernel parameter like TZ=+0200 (numeric notation used
> > in EMail)
>
> Both are already part of the hwclock program.
>
> > 3) Enhance routines that set the system time to update the RTC
> > as well
>
> Your wording is ambiguous, so I'll deal with both possible meanings:
>
> a. There are various programs available to synchronise the system
> clock with some external time standard. I use rdate as part of
> my dial up script, and a friend of mine uses a program that
> synchronises his system clock with that broadcast on teletext.
I mean: settimeofday() and related functions should also set the RTC
immediately. That's what the average user expects the program to do.
Confusion arises if not.
>
> b. The hwclock program also has the ability to set the RTC from
> the system clock.
Maybe let's name a popular example: When installing SuSE Linux,
there's no way to set the system time (other than escaping to a shell
and calling "date -s"), and the timezone is zero during installation.
The RTC is asumed to be UTC. After installation, the system time
warps. (You can see it when checking the installation times with "rpm
-qi"). If things were just fine, we would not have such problems.
>
> The combination of those two means that it is already possible to both
> synchronise the RTC with an external time standard and to ensure that
> the kernel is itself so synchronised.
I think I know what you are talking about ;-)
>
> > I some people can convince me that it's a good idea, I might
> > develop a patch...
>
> Unfortunately, it's already been dealt with in userspace, so any
> kernel patch you developed would be unlikely to be applied anyway.
Aha.
Regards,
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/