dmesg -T and the actual time a message was produced, noted on
current-users by Geoff Wing (Oct 27, 2018).
The size of the offset would depend upon architecture, and processor,
but was the delay from starting the clocks to initialising the time
of day (after mounting root, in case that is needed).
Change the kernel to set boottime to be the time at which the
clocks were started, rather than the time at which it is init'd
(by subtracting the interval between).
Correct dmesg to properly compute the ToD based upon the
boottime (which is a timespec, not a timeval, and has been
since Jan 2009) and the time logged in the message.
Note that this can (rarely) be 1 second earlier than date reports.
This occurs when the time when the message was logged was actually
in the next second, but the timecounters have not yet processed
the tick, and so the time of the last tick, near the end of the
previous second, is reported instead. Since times are always
truncated, rather than rounded, it is occasionally possible to
observe that disparity (if you try hard enough).
IOW: sys/kern/subr_prf.c:addtstamp() uses getnanouptime() rather
than nanouptime().
Note in dmesg(8) that -T conversions are gibberish other than
when the message comes from current the running kernel. (It
could be fixed when -M is used, for messages generated by the
kernel whose corpse is being observed. But hasn't been...)
- pass intmax to fmtydhmsf instead of time_t to avoid extra conversions.
- make -TTT mean "always keep 3 decimal digits of duration precision" (ie:
always print ms) (including trailing 0's, even .000 if it happens)
- make -T (all forms) be subject to the locale (obey the radix character)
- don't print ymd, since that would require calendar calculations to get
right.
decimal fractions of a second (as they should be) rather than integer
milliseconds (ie nnn.1means nnn seconds and 1/10 of a second, not
nnn seconds, and 1 millisecond). While here convert some inappropriate
time_t usage to intmax_t which works better (int, or long, would probably
work just as well).
nanoseconds, 9 digits) the kernel happens to send in the timestamps
in log messages.
Output (numeric) timestamps (when produced) are unchanged and always
in microseconds (for now).
