Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)

[Prarit Bhargava <prarit@redhat.com>]

On 07/19/2017 03:23 AM, Thomas Gleixner wrote:
> On Tue, 18 Jul 2017, Mark Salyzyn wrote:
>> On 07/18/2017 03:35 PM, Thomas Gleixner wrote:
>>> There was some discussion about making the clock source for dmesg time
>>> stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
>>> patches looked sensible, but there was some showstopper vs. the user space
>>> dmesg utility. See:
>>
>> The timestamps are useful for the 'second' purpose of these patches when
>> dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
>> is selected. Having rtc_show_time a single point for switching this no doubt
>> helps,
>> not hinders, that dmesg issue.
>>
>> The inflection points would still serve a purpose, still need
>> suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
>> us with their timestamps, as I checked and the only tools that use those are
>> for log synchronization. We may be able to do away with them on REALTIME
>> dmesg'ing; but the standardization of the message as a marker would have a
>> legacy purpose (!)
>>
>> NB: We have a similar configuration for the user space logger, which can be
>> configured to report in MONOTONIC time. We have yet to have a vendor
>> use the feature, opting for REALTIME logging for user space activities.
>> Our klogd (which runs at background priority and is batched) manages a
>> histogram relationship between MONOTONIC and REALTIME helped by these
>> prints and incorporates the REALTIME dmesg logs merged into our user
>> space logging database.
> 
> There is another option to remedy this and the dmesg tooling issues:
> 
> Instead of switching the time stamps in dmesg to a different clock we might
> as well have an optional secondary timestamp. So instead of:
> 
>  [  341.590930] wlan0: associated
> 
> you would get:
> 
>  [  341.590930] [ sec.usec] wlan0: associated
> 
> where the second time stamp would be CLOCK_REALTIME/BOOTTIME.
> 
> That should also solve Prarits problem, hmm?

It would but I would prefer a single time stamp be printed than two.  I think
two timestamps is adding confusion to the output from a end-users point of view.

Mark, why don't we get together and fixup my original patchset to make sure it
meets your needs?  It will fix both of our issues albeit not necessarily in the
text format you want it.

P.

> 
> Thanks,
> 
> 	tglx
> 
>