Messages in this thread | | | Date | Sat, 22 May 1999 08:49:33 +1000 | From | Richard Gooch <> | Subject | Re: i386/RTC: old problem, new solution? |
| |
Riley Williams writes: > Hi Richard. > > In fact, there already is a patch in the kernel: > > CONFIG_APM_RTC_IS_GMT, but it's a temporary hack, until a better > > scheme is implemented. The reason is that the kernel needs to > > know the timezone the RTC is stored in when restoring the system > > clock after a suspend/resume cycle. Automatically computing the > > difference has its problems. > > I have to admit that I wasn't aware of that patch, and by the sounds > of it, it could do with being extended to cover the boot scenario > where the kernel currently has to wait until `hwclock --hctosys` or > `hwclock --utc --hctosys` is run to discover what timezone to use.
Check Rafael's recent message. He's now agreeing with me that for the purposes of fsck timestamps for the root FS, you don't need kernel help. You simply run hwclock before you check the root FS. If this doesn't happen it's a distribution bug. It's not the kernel's problem.
Responding to your other message about timestamps for race conditions: yes, if you're going to use them, you need sub-microsecond resolution. If you have a TSC, you may as well use that.
Nevertheless, I'm still not convinced that this is worth the effort. However, if you feel strongly, write a patch and submit it. Just make sure it's a config option (most of us don't want to know which nanosecond a message was generated).
Regards,
Richard....
- 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/
| |