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

[Don Slutz <dslutz@verizon.com>]

On 03/11/14 11:08, Ian Campbell wrote:
> On Tue, 2014-03-11 at 14:57 +0000, Andrew Cooper wrote:
>> 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.
> I suppose.
>
> If we have to keep the various options can't we at least replace date
> with datems instead of adding another? I suppose the objections are that
> it is too long, but frankly if Don as proponent of dated timestamps
> happy with that then anyone who cares about the length can use the
> "boot" format anyway.

I am happy with only the longer dated timestamps.

    -Don Slutz

>>>>>>    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.
> Ah, I see.
>
> Well, I suppose all the comments I've addressed to you ought to be
> addressed to the folks objecting to the removal then ;-)
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel