> Can anyone think of a good reason as to why sys_settimeofday() should
> not update the hardware clock (aka RTC) as well?
Because that would be a broken design.
And it causes problems as well.
On some architectures kernel access to RTC hangs.
Probably the kernel doesnt know what timezone RTC is supposed to be in.
It doesnt know whether RTC is supposed to be in BCD or in binary.
It doesnt know whether a century byte is supported.
It doesnt know the epoch.
> One possible reason is if different OSes have a different idea of what
> the "epoch" is (as is the case on the Alpha, for example), but this is
> not an issue in the particular case I'm interested in, so I'm
> wondering if there are any other reasons. Fundamentally, I think it's
> needlessly confusing for a user to have to remember to update the
> hardware clock separately.
If two things must happen simultaneously, give the user a tool that
does these two things simultaneously - call it "setclock" or so,
but do not patch the kernel.
By the way, I think hwclock is better at setting the time than the kernel is.
I have met people with hardware (Alpha's, I think) where /dev/rtc fails
but "hwclock --directisa" works. I know of no examples of the reverse situation.
Andries
-
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/