Re: "dmesg -T" date doesn't match "date" output

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sun, Oct 28, 2018 at 04:45:58PM +0700, Robert Elz wrote:

> 1.  when the firmware is told to boot
> 2.  when the boot loader gets control from the firmware
> 3.  when the kernel first starts executing.
3a. when the kernel has started clock
3b. when the kernel has mounted root
> 4.  When the kernel starts init
> 5.  When /etc/rc finishes

$uptime is counted from 3a (maybe still starting at 1 instead of 0 ?).

$time is started either between 3 and 3a (with TOD) or at 3b (without TOD),
in the latter case it has only a rough relationship with the real world
but even with TOD it's usually only precise to a second.

$boottime is currently the $time at 3b, because earlier than that we may
not have a useful $time value.

For absolute timestamps in dmesg it's not necessary to change how we
define $boottime. We just have to find a suitable value for $time
at 3a so that this value can be added to the relative timestamp in the
log to get an absolute time.

The easiest way to find such a value is to make a copy of $uptime
when $boottime is set. We _could_ also adjust $boottime directly,
changing how it is defined. Or we _could_ just expose the copied
$uptime value and let dmesg do the computation.

Of course we could also sample $uptime and $time later to track
adjustments done by e.g. NTP. But that's often useless as we
aren't interested in real world time when comparing logs but
in what a system considered as absolute time when the log was
written.

If you are really interested in real time, and there are use cases
for this, then you should ignore $boottime altogether and just
subtract $uptime from the current time to get a proper offset.


N.B. if the message buffer is big enough, you'll get dmesg entries
from several 'epochs' that are related to different values of
$boottime. To handle this, you have to log when an epoch starts
and what value of $boottime was valid then. But matching this with
real time is difficult.


Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."