[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
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 
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 
  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?


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).

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.

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.


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 ;-)


Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.