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

[Don Slutz <dslutz@xxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel