> umm, this thread is going in circles. settimeofday(NULL, &tz)
> provides the mechanism to do this. in fact, my original post was
> just a question about where to stick the user-level bits. i have it
> in the update daemon, for example, as it has minimal overhead (most
> likely less than a regularly scheduled cron job) and you never need
> to call settimeofday unless the timezone actually changes. given
> that update runs every 10 seconds, you even get pretty good
> resolution on a timezone switch.
Make the wake-up semantics smarter... ie. if we know it's 37 seconds
away from a zone-change, sleep for 37 seconds or less. If we wake up
three times (10s each, so blah & sync), then the fourth time sleep
for only 7 seconds at most.
10 seconds is a long time -- consider someone compiling a large
program (or kernel) on an affected FS when the zone change occurs.
Either that, or have the VFS know about time-offsets on a per mount
basis, and a pending time-offset update, so the VFS knows that it n
ticks, the offset will change too m or something -- it still probably
won't be race free, but hopefully close too it.
-cw
-
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/