Well, without the patch the boottime would change as you change the
system time. So if you set the system time forward an hour, your
boottime would go forward as well, and so forth.
With the patch, the boottime would remain the same regardless of
changes to the system time. IMHO, this is probably for the better,
since now as it stands we have issues with the boottime changing under
us due to the way xtime and jiffies are updated. To me, having an
unchanging boottime is more profitable than one that changes.
Applications could use the value as a reliable absolute time
reference. For example, to find out the absolute time a process
started, you can add the boottime and the starttime of the process,
the latter being in jiffies after the system booted, and not expect
this value to change.
The tradeoff, though, is that it is possible to have the boottime
greater than the current time if you set the system time back enough.
I think setting it forward is a non-issue. I could be wrong but so
far I believe that is worth putting up this with tradeoff given the
benefits of an unchanging boottime time. There is no affect obtaining
the system uptime - people shouldn't go calculating system time minus
boottime, since uptime itself is provided. Moreover, a similar
problem is what to do with file modification times in the future - we
do nothing.
What do you or others think? If people wanted to keep the old
semantics of a boottime that changed with the system time then we'll
need another way to avoid the wobble.
-- Kingsley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/