Re: [PATCH v5 5/5] xen/console: Traditional console timestamps including milliseconds

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 11/03/14 14:18, Ian Campbell wrote:
> On Tue, 2014-03-11 at 14:02 +0000, Andrew Cooper wrote:
>> On 11/03/14 13:54, Ian Campbell wrote:
>>> On Tue, 2014-03-11 at 11:08 +0000, Andrew Cooper wrote:
>>>> On 11/03/14 11:06, David Vrabel wrote:
>>>>> On 11/03/14 10:55, Andrew Cooper wrote:
>>>>>> On 11/03/14 10:13, Ian Campbell wrote:
>>>>>>> On Fri, 2014-03-07 at 17:28 +0000, Andrew Cooper wrote:
>>>>>>>> Suggested-by: Don Slutz <dslutz@verizon.com>
>>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>> CC: Keir Fraser <keir@xen.org>
>>>>>>>> CC: Jan Beulich <JBeulich@suse.com>
>>>>>>>> CC: Ian Campbell <ian.campbell@citrix.com>
>>>>>>>> CC: Stefano Stabellini <stefano.stabellini@citrix.com>
>>>>>>>> CC: Tim Deegan <tim@xen.org>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> The change in arm is only for the sake of compilation - the function is a
>>>>>>>> no-op.
>>>>>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>>>
>>>>>>>> v5: Correct check for null in wallclock_time()
>>>>>>>> ---
>>>>>>>>  docs/misc/xen-command-line.markdown |    4 +++-
>>>>>>>>  xen/arch/arm/time.c                 |    2 +-
>>>>>>>>  xen/arch/x86/time.c                 |   10 +++++++---
>>>>>>>>  xen/drivers/char/console.c          |   11 ++++++++++-
>>>>>>>>  xen/include/xen/time.h              |    2 +-
>>>>>>>>  5 files changed, 22 insertions(+), 7 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
>>>>>>>> index e437091..ced5eca 100644
>>>>>>>> --- a/docs/misc/xen-command-line.markdown
>>>>>>>> +++ b/docs/misc/xen-command-line.markdown
>>>>>>>> @@ -275,7 +275,7 @@ cleared.  This allows a single port to be shared by two subsystems
>>>>>>>>  makes sense on its own.
>>>>>>>>  
>>>>>>>>  ### console\_timestamps
>>>>>>>> -> `= none | date | boot`
>>>>>>>> +> `= none | date | datems | boot`
>>>>>>> I think someone (David V?) asked this earlier but I don't remember a
>>>>>>> response: Why do we need to support multiple timestamp formats? Can't we
>>>>>>> just pick one which has reasonable accuracy/information content and
>>>>>>> stick with it?
>>>>>>>
>>>>>>> Ian.
>>>>>>>
>>>>>> That is posed as an RFC in patch 0, which has gone without comment for
>>>>>> several versions of this series now.
>>>>>>
>>>>>> XenServer has timestamps enabled by default, and in my opinion is too
>>>>>> long (space wise) and insufficiently precise.  That is why I introduced
>>>>>> the linux-style timestamps.
>>>>>>
>>>>>> Don has expressed interest in keeping the existing format, preferring it
>>>>>> to linux-style.
>>> Did he say why? (sorry, I'm catching up on mail backlog, so maybe I
>>> missed this.
>> Yes, the same as Sander hooked off this thread.  To match entries in the
>> Xen console with other log files.
> Does Linux have a similar datestamped mode then?

No - Linux only has seconds/microseconds.

The Xen console timetstamp format (none by default) has been full CMOS
information since 7ee27216bf039c6de2 in 2007.

>
>> This patch is Suggested-by: Don, given the previous dicussions
>>
>>> Are there examples of the various formats somewhere?
>> In the patched markdown for patches 4 and 5, as well as in the enum
>> TSM_* from the same two patches.
> Found it. For ref:
>  * `none`: No timestamps
>  * `date`: Date and time information
>      * `[YYYY-MM-DD HH:MM:SS]`
> +* `datems`: Date and time, with milliseconds
> +    * `[YYYY-MM-DD HH:MM:SS.mmm]`
>  * `boot`: Seconds and microseconds since boot
>      * `[SSSSSS.uuuuuu]`
>
> Perhaps rather than increase the already unsatisfactorily large number
> of options we cold drop YYYY- in favours of .mmm? It's seems unlikely
> that the year would be of interest, you'd need two messages >365 days
> apart which were also ambiguous.

Without the YYYY-, you loose clarity between English and American dates,
which I suspect will cause more confusion in the longrun.


>
>>>>   Furthermore, the precision issue has been addressed, at
>>>>>> the expense of extra length, space wise.
>>>>> Wallclock date/time timestamps may be better served by a klogd like
>>>>> logging daemon in dom0 (but such a daemon doesn't exist yet).
>>>>>
>>>>> David
>>>> Not if you want timestamps on the serial console,
>>> At least around here the serial console server takes care of that most
>>> of the time.
>>>
>>> Ian.
>> If you are purely logging them, but not if you are working on the serial
>> console itself, which is what I find myself doing for a surprisingly
>> large amount of my work.
> You know what day it is though, don't you? And even if not surely there
> are terminal emulators which can date stamp things for you.
>
> Ian.
>
>

I know what day it is, which is why my preferred timestamps are linux
style.  I find myself far more concerned with whether the few log lines
preceding a crash are immediately related, or happened some unrelated
time in the past.

I only maintained the old full date format because there was an
objection to me removing it in v1 of the series.

~Andrew