Date: Sun, 28 Oct 2018 07:45:12 -0000 (UTC)
From: mlel...@serpens.de (Michael van Elst)
Message-ID: <pr3pe7$lju$1...@serpens.de>
| We could save the uptime value at that point and make dmesg -T adjust
| the timestamps accordingly
I think we need to define just what is boottime? sysctl(7) is of no help at
all "the time that the system was booted" ...
I see five instants during the startup sequence that could be that magic
time ...
1. when the firmware is told to boot, either implicitly via power on,
or via some kind of user command. That time is generally not
available to us, so while it is in some sense the most basic and
purest value, we should just ignore this one.
2. when the boot loader gets control from the firmware (usually after some
kind of self test). This one is at least possible to manage in some cases,
but there are many boot loaders, and we don't control all of them, and
cannot for some (since in some systems the firmware contains the boot
loader), so again we should abandon that one.
3. when the kernel first starts executing. Here we at least have control,
though on many systems there is no easy way to measure the delay
between when the kernel starts, and when it can first start counting
time (when some kind of clock starts running), so getting it to the
microsecond accuracy that the timeval that is kern.boottime promises
would be difficult, but we could at least approximate this one.
4. When the kernel starts init (user level processes start executing).
This one appears to be close to what we have now, but from a normal
user's point of view is the least intuitive of all of these (the
transition from the kernel configuring, to /etc/rc configuring is almost
invisible ... the console messages just change colour).
5. When /etc/rc finishes, and user logins become possible (which would
mean poking it from userland, as this transition is mostly invisible to the
kernel.)
dmesg is currently assuming 3, as that's when the timestamps in the kernel
log messages are relative too. But 4 is what we have - hence the
disparity in the values from dmesg -T and date.
I am not sure that we will get universal (or even rough majority) consensus
on which of the three plausible values should be the boottime, so I would
propose adding three new sysctl variables, two long, one int - the first two
containing microsend offsets of events 4 and 5 from (as close as we can
get to) 3, the one for 4 would be kernel write only, the one for 5 would be
0 until written by a root process (last step of /etc/rc processing, and for
this, in /etc/rc itself so it cannot be defeated by rc.d/* ordering). I'd
suggest making it "write once" (can be written if currently 0, not otherwise).
The int would be (effectively) an enum expressing system preference for how
boottime is reported - which of the three values is regarded as the system
boot time for display to users - that should be root read/write (can be
adjusted any time).
Then we can make kern.boottime return any of the 3 plausible values,
perhaps depending upon the new enum sysctl, or simply defining it
as one of the three, and userlevel can calculate the others from it
(once we define what it is) combined with the values of the new sysctl
vars (as needed.)
Then "uptime" (and the similar display in "w") can be updated to report
the interval since the local system (manager)'s idea of when it was booted,
and dmesg can adjust is timestamps to be relative (including negative
when that happens) relative to that time (and dmesg -T would simply be
"right").
Opinions?
kre
ps: perhaps iint64_t rather than long, as a 32 bit long could be stretched
counting microseconds betwween events 3 and 5 if there's some time spent
in single user mode along the way.
