On Tue, 18 Jul 2017, Mark Salyzyn wrote:
Go directly to the rtc for persistent wall clock time and print.That's a horrible idea, really. And there is no point at all.
Useful if REALTIME is required to be logged in a low level power
management function or when clock activities are suspended. An
aid to permit user space alignment of kernel activities.
+void rtc_show_time(const char *prefix_msg)It calls getnstimeofday(), which is wrong to begin with as we switch
+{
+ struct timespec ts;
+ struct rtc_time tm;
+
+ getnstimeofday(&ts);
everything in kernel to the 64bit variants.
Again, oops, changed rtc_time_to_tm to rtc_time64_to_tm as requested, did not change other pieces.
+ rtc_time64_to_tm(ts.tv_sec, &tm);This is even more wrong as rtc_time64_to_tm is for 64 bit wide second
values....
+ pr_info("%s %d-%02d-%02d %02d:%02d:%02d.%09lu UTC\n",Why on earth do you need to print that information in RTC format? What's
+ prefix_msg ? prefix_msg : "Time:",
+ tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+ tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
wrong with just doing:
pr_info("My so important log message %lld\n", ktime_get_real_seconds());
This is part of triage and post-analysis, there is no user space call that can be made after the fact to correlate MONOTONIC time with REALTIME. The historgram for the relationship between the two time formats is built up in user space based on batched analysis of the kernel logs. Although the values slip because of ntp and other sources, suspend/resume/hibernate/restore and shutdown are definitive points of interest for analysis. The analysis is performed on klogd data which has a longer logging span than the internal buffer.
and then decoding the seconds in post processing? That's completely
sufficient as you intend that for logging. Correlation with user space
CLOCK_REALTIME is even simpler as this is the same as reading it from user
space.
tracepoints are disabled on field devices. As is debugfs. This is not logging/debugging, but field battery and power analysis. Some of the data shows up in the Battery Settings screen on the devices. We also _benefit_ from this information when correlating kernel logs with user space logs during triage.
If your main intention is logging/debugging, then you can just use
tracepoints. The tracer allows correlation to user space tracing already.
So unless you can come up with a reasonable explanation why all this voodoo
is required, this is going nowhere.
Thanks,
tglx