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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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@xxxxxxxxxxx>
> >>>>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >>>>>>>> CC: Keir Fraser <keir@xxxxxxx>
> >>>>>>>> CC: Jan Beulich <JBeulich@xxxxxxxx>
> >>>>>>>> CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>>>>>>> CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> >>>>>>>> CC: Tim Deegan <tim@xxxxxxx>
> >>>>>>>>
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> The change in arm is only for the sake of compilation - the function 
> >>>>>>>> is a
> >>>>>>>> no-op.
> >>>>>>> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >>>>>>>
> >>>>>>>> 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.

> >>>>   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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel