[PATCH v5 0/5] Improvements to console timestamps

[PATCH v5 0/5] Improvements to console timestamps

[Andrew Cooper]

This series aims to improve on the current implementation of console
timestamps in Xen.

Patch 1 is just movement of wallclock_time()s declaration to common code.

Patch 2 changes Xen's idea of when time starts, from when the BSPs TSC was 0,
to when Xen boots.

Patch 3 guesses at AP time calibration earlier during boot, so printk()s using
the new console timestamp have a real stamp, rather than 0s.

Patch 4 is the meat of the series, adding a new timestamp implementation to
printk_start_of_line().

Patch 5 comes as a intermediate suggestion, to retain the old timestamp style,
but to display milliseconds as well.

Finally, from discussion in the office, it has been suggested that the
timestamp mode/format would be better as build-time configuration rather than
boot-time configuration.  I am on the fence with this regard, but
comments/thoughts are very welcome.

~Andrew

[PATCH v5 1/5] xen/time: Move wallclock_time() declaration into common code

[Andrew Cooper]

It is called from common code, but has architecture specific implementations.
Have one declaration instead of two.

No functional change.

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>
---
 xen/include/asm-arm/time.h |    3 ---
 xen/include/asm-x86/time.h |    3 ---
 xen/include/xen/time.h     |    1 +
 3 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
index 9d302d3..d10c737 100644
--- a/xen/include/asm-arm/time.h
+++ b/xen/include/asm-arm/time.h
@@ -12,9 +12,6 @@ static inline cycles_t get_cycles (void)
         return 0;
 }
 
-struct tm;
-struct tm wallclock_time(void);
-
 /* List of timer's IRQ */
 enum timer_ppi
 {
diff --git a/xen/include/asm-x86/time.h b/xen/include/asm-x86/time.h
index 147b39e..c01b0a2 100644
--- a/xen/include/asm-x86/time.h
+++ b/xen/include/asm-x86/time.h
@@ -48,9 +48,6 @@ int dom0_pit_access(struct ioreq *ioreq);
 
 int cpu_frequency_change(u64 freq);
 
-struct tm;
-struct tm wallclock_time(void);
-
 void pit_broadcast_enter(void);
 void pit_broadcast_exit(void);
 int pit_broadcast_is_available(void);
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 95b4b91..3eb5b63 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -48,6 +48,7 @@ struct tm {
     int     tm_isdst;       /* daylight saving time */
 };
 struct tm gmtime(unsigned long t);
+struct tm wallclock_time(void);
 
 #define SYSTEM_TIME_HZ  1000000000ULL
 #define NOW()           ((s_time_t)get_s_time())
-- 
1.7.10.4

Re: [PATCH v5 1/5] xen/time: Move wallclock_time() declaration into common code

[Ian Campbell]

On Fri, 2014-03-07 at 17:28 +0000, Andrew Cooper wrote:
> It is called from common code, but has architecture specific implementations.
> Have one declaration instead of two.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> CC: Stefano Stabellini <stefano.stabellini@citrix.com>
> CC: Tim Deegan <tim@xen.org>
> ---
>  xen/include/asm-arm/time.h |    3 ---
>  xen/include/asm-x86/time.h |    3 ---
>  xen/include/xen/time.h     |    1 +
>  3 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/xen/include/asm-arm/time.h b/xen/include/asm-arm/time.h
> index 9d302d3..d10c737 100644
> --- a/xen/include/asm-arm/time.h
> +++ b/xen/include/asm-arm/time.h
> @@ -12,9 +12,6 @@ static inline cycles_t get_cycles (void)
>          return 0;
>  }
>  
> -struct tm;
> -struct tm wallclock_time(void);
> -
>  /* List of timer's IRQ */
>  enum timer_ppi
>  {
> diff --git a/xen/include/asm-x86/time.h b/xen/include/asm-x86/time.h
> index 147b39e..c01b0a2 100644
> --- a/xen/include/asm-x86/time.h
> +++ b/xen/include/asm-x86/time.h
> @@ -48,9 +48,6 @@ int dom0_pit_access(struct ioreq *ioreq);
>  
>  int cpu_frequency_change(u64 freq);
>  
> -struct tm;
> -struct tm wallclock_time(void);
> -
>  void pit_broadcast_enter(void);
>  void pit_broadcast_exit(void);
>  int pit_broadcast_is_available(void);
> diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
> index 95b4b91..3eb5b63 100644
> --- a/xen/include/xen/time.h
> +++ b/xen/include/xen/time.h
> @@ -48,6 +48,7 @@ struct tm {
>      int     tm_isdst;       /* daylight saving time */
>  };
>  struct tm gmtime(unsigned long t);
> +struct tm wallclock_time(void);
>  
>  #define SYSTEM_TIME_HZ  1000000000ULL
>  #define NOW()           ((s_time_t)get_s_time())

[PATCH v5 2/5] x86/time: Always count s_time from Xen boot

[Andrew Cooper]

From: Tim Deegan <tim@xen.org>

Timestamped printks() can call NOW() before init_xen_time().
Set a baseline TSC as soon as we've calibrated the TSC rate,
so that NOW() consistently counts from boot time.

Signed-off-by: Tim Deegan <tim@xen.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
---
v2: use TSC from __start() rather than from early_time_init().
v3: remove later reset of TSC baseline from init_xen_time().
v4: shuffle boot_tsc_stamp definition and use of 'this_cpu()'.
---
 xen/arch/x86/boot/head.S |    6 ++++++
 xen/arch/x86/time.c      |   10 ++++++----
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index b12eefb..1777c17 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -136,6 +136,12 @@ __start:
         /* Check for availability of long mode. */
         bt      $29,%edx
         jnc     bad_cpu
+
+        /* Stash TSC to calculate a good approximation of time-since-boot */
+        rdtsc
+        mov     %eax,sym_phys(boot_tsc_stamp)
+        mov     %edx,sym_phys(boot_tsc_stamp+4)
+
         /* Initialise L2 boot-map page table entries (16MB). */
         mov     $sym_phys(l2_bootmap),%edx
         mov     $PAGE_HYPERVISOR|_PAGE_PSE,%eax
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 000191b..4f4de22 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -84,6 +84,9 @@ static u16 pit_stamp16;
 static u32 pit_stamp32;
 static bool_t __read_mostly using_pit;
 
+/* Boot timestamp, filled in head.S */
+u64 __initdata boot_tsc_stamp;
+
 /*
  * 32-bit division of integer dividend and integer divisor yielding
  * 32-bit fractional quotient.
@@ -1433,9 +1436,6 @@ int __init init_xen_time(void)
 
     open_softirq(TIME_CALIBRATE_SOFTIRQ, local_time_calibration);
 
-    /* System time (get_s_time()) starts ticking from now. */
-    rdtscll(this_cpu(cpu_time).local_tsc_stamp);
-
     /* NB. get_cmos_time() can take over one second to execute. */
     do_settime(get_cmos_time(), 0, NOW());
 
@@ -1453,9 +1453,11 @@ int __init init_xen_time(void)
 /* Early init function. */
 void __init early_time_init(void)
 {
+    struct cpu_time *t = &this_cpu(cpu_time);
     u64 tmp = init_pit_and_calibrate_tsc();
 
-    set_time_scale(&this_cpu(cpu_time).tsc_scale, tmp);
+    set_time_scale(&t->tsc_scale, tmp);
+    t->local_tsc_stamp = boot_tsc_stamp;
 
     do_div(tmp, 1000);
     cpu_khz = (unsigned long)tmp;
-- 
1.7.10.4

[PATCH v5 3/5] x86/time: Initialise time earlier during start_secondary()

[Andrew Cooper]

It is safe to do so, and useful for "[second.microseconds]" style timestamps
on printk()s during secondary bringup.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/smpboot.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 42b8a59..5014397 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -347,6 +347,8 @@ void start_secondary(void *unused)
 
     percpu_traps_init();
 
+    init_percpu_time();
+
     cpu_init();
 
     smp_callin();
@@ -381,8 +383,6 @@ void start_secondary(void *unused)
     cpumask_set_cpu(cpu, &cpu_online_map);
     unlock_vector_lock();
 
-    init_percpu_time();
-
     /* We can take interrupts now: we're officially "up". */
     local_irq_enable();
     mtrr_ap_init();
-- 
1.7.10.4

Re: [PATCH v5 3/5] x86/time: Initialise time earlier during start_secondary()

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 1298 bytes --]

On Fri, Mar 7, 2014 at 5:28 PM, Andrew Cooper <andrew.cooper3@citrix.com>wrote:

> It is safe to do so, and useful for "[second.microseconds]" style
> timestamps
> on printk()s during secondary bringup.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
>

I know Jan is uncertain about this one. I also don't like moving functions
around in AP bringup very much... I'm kind of on the fence with this one,
but I think it's okay here.

Acked-by: Keir Fraser <keir@xen.org>

---
>  xen/arch/x86/smpboot.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
> index 42b8a59..5014397 100644
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -347,6 +347,8 @@ void start_secondary(void *unused)
>
>      percpu_traps_init();
>
> +    init_percpu_time();
> +
>      cpu_init();
>
>      smp_callin();
> @@ -381,8 +383,6 @@ void start_secondary(void *unused)
>      cpumask_set_cpu(cpu, &cpu_online_map);
>      unlock_vector_lock();
>
> -    init_percpu_time();
> -
>      /* We can take interrupts now: we're officially "up". */
>      local_irq_enable();
>      mtrr_ap_init();
> --
> 1.7.10.4
>
>

[-- Attachment #1.2: Type: text/html, Size: 2200 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH v5 4/5] xen/console: Provide timestamps as an offset since boot

[Andrew Cooper]

This adds a new "Linux style" console timestamp method, which is shorter and
more useful than the current date/time timestamps with single-second
granularity.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>

---
v5: Default to none. Dont warn about bad options
---
 docs/misc/xen-command-line.markdown |   15 ++++++++--
 xen/drivers/char/console.c          |   56 +++++++++++++++++++++++++++++------
 2 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 15aa404..e437091 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -275,11 +275,20 @@ cleared.  This allows a single port to be shared by two subsystems
 makes sense on its own.
 
 ### console\_timestamps
-> `= <boolean>`
+> `= none | date | boot`
 
-> Default: `false`
+> Default: `none`
+
+Specify which timestamp format Xen should use for each console line.
+
+* `none`: No timestamps
+* `date`: Date and time information
+    * `[YYYY-MM-DD HH:MM:SS]`
+* `boot`: Seconds and microseconds since boot
+    * `[SSSSSS.uuuuuu]`
 
-Flag to indicate whether include a timestamp with each console line.
+For compatibility with the older boolean parameter, specifying
+`console_timestamps` alone will enable the `date` option.
 
 ### console\_to\_ring
 > `= <boolean>`
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 7d4383c..e9f3fe1 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -49,8 +49,17 @@ static bool_t __read_mostly opt_console_to_ring;
 boolean_param("console_to_ring", opt_console_to_ring);
 
 /* console_timestamps: include a timestamp prefix on every Xen console line. */
-static bool_t __read_mostly opt_console_timestamps;
-boolean_param("console_timestamps", opt_console_timestamps);
+enum con_timestamp_mode
+{
+    TSM_NONE,          /* No timestamps */
+    TSM_DATE,          /* [YYYY-MM-DD HH:MM:SS] */
+    TSM_BOOT           /* [SSSSSS.uuuuuu] */
+};
+
+static enum con_timestamp_mode __read_mostly opt_con_timestamp_mode = TSM_NONE;
+
+static void parse_console_timestamps(char *s);
+custom_param("console_timestamps", parse_console_timestamps);
 
 /* conring_size: allows a large console ring than default (16kB). */
 static uint32_t __initdata opt_conring_size;
@@ -546,23 +555,52 @@ static int printk_prefix_check(char *p, char **pp)
             ((loglvl < upper_thresh) && printk_ratelimit()));
 } 
 
+static void __init parse_console_timestamps(char *s)
+{
+    if ( *s == '\0' || /* Compat for old booleanparam() */
+         !strcmp(s, "date") )
+        opt_con_timestamp_mode = TSM_DATE;
+    else if ( !strcmp(s, "boot") )
+        opt_con_timestamp_mode = TSM_BOOT;
+    else if ( !strcmp(s, "none") )
+        opt_con_timestamp_mode = TSM_NONE;
+}
+
 static void printk_start_of_line(const char *prefix)
 {
     struct tm tm;
     char tstr[32];
+    uint64_t sec, nsec;
 
     __putstr(prefix);
 
-    if ( !opt_console_timestamps )
-        return;
+    switch ( opt_con_timestamp_mode )
+    {
+    case TSM_DATE:
+        tm = wallclock_time();
 
-    tm = wallclock_time();
-    if ( tm.tm_mday == 0 )
+        if ( tm.tm_mday == 0 )
+            return;
+
+        if ( opt_con_timestamp_mode == TSM_DATE )
+            snprintf(tstr, sizeof(tstr), "[%04u-%02u-%02u %02u:%02u:%02u] ",
+                     1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
+                     tm.tm_hour, tm.tm_min, tm.tm_sec);
+        break;
+
+    case TSM_BOOT:
+        sec = NOW();
+        nsec = do_div(sec, 1000000000);
+
+        snprintf(tstr, sizeof(tstr), "[%5"PRIu64".%06"PRIu64"] ",
+                 sec, nsec / 1000);
+        break;
+
+    case TSM_NONE:
+    default:
         return;
+    }
 
-    snprintf(tstr, sizeof(tstr), "[%04u-%02u-%02u %02u:%02u:%02u] ",
-             1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
-             tm.tm_hour, tm.tm_min, tm.tm_sec);
     __putstr(tstr);
 }
 
-- 
1.7.10.4

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

[Andrew Cooper]

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.

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`
 
 > Default: `none`
 
@@ -284,6 +284,8 @@ Specify which timestamp format Xen should use for each console line.
 * `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]`
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 81e3e28..22e94bb 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -282,7 +282,7 @@ void domain_set_time_offset(struct domain *d, int32_t time_offset_seconds)
     /* XXX update guest visible wallclock time */
 }
 
-struct tm wallclock_time(void)
+struct tm wallclock_time(uint64_t *ns)
 {
     return (struct tm) { 0 };
 }
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 4f4de22..f904af2 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1646,15 +1646,19 @@ int dom0_pit_access(struct ioreq *ioreq)
     return 0;
 }
 
-struct tm wallclock_time(void)
+struct tm wallclock_time(uint64_t *ns)
 {
-    uint64_t seconds;
+    uint64_t seconds, nsec;
 
     if ( !wc_sec )
         return (struct tm) { 0 };
 
     seconds = NOW() + SECONDS(wc_sec) + wc_nsec;
-    do_div(seconds, 1000000000);
+    nsec = do_div(seconds, 1000000000);
+
+    if ( ns )
+        *ns = nsec;
+
     return gmtime(seconds);
 }
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e9f3fe1..96908b6 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -53,6 +53,7 @@ enum con_timestamp_mode
 {
     TSM_NONE,          /* No timestamps */
     TSM_DATE,          /* [YYYY-MM-DD HH:MM:SS] */
+    TSM_DATE_MS,       /* [YYYY-MM-DD HH:MM:SS.mmm] */
     TSM_BOOT           /* [SSSSSS.uuuuuu] */
 };
 
@@ -560,6 +561,8 @@ static void __init parse_console_timestamps(char *s)
     if ( *s == '\0' || /* Compat for old booleanparam() */
          !strcmp(s, "date") )
         opt_con_timestamp_mode = TSM_DATE;
+    else if ( !strcmp(s, "datems") )
+        opt_con_timestamp_mode = TSM_DATE_MS;
     else if ( !strcmp(s, "boot") )
         opt_con_timestamp_mode = TSM_BOOT;
     else if ( !strcmp(s, "none") )
@@ -577,7 +580,8 @@ static void printk_start_of_line(const char *prefix)
     switch ( opt_con_timestamp_mode )
     {
     case TSM_DATE:
-        tm = wallclock_time();
+    case TSM_DATE_MS:
+        tm = wallclock_time(&nsec);
 
         if ( tm.tm_mday == 0 )
             return;
@@ -586,6 +590,11 @@ static void printk_start_of_line(const char *prefix)
             snprintf(tstr, sizeof(tstr), "[%04u-%02u-%02u %02u:%02u:%02u] ",
                      1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
                      tm.tm_hour, tm.tm_min, tm.tm_sec);
+        else
+            snprintf(tstr, sizeof(tstr),
+                     "[%04u-%02u-%02u %02u:%02u:%02u.%03"PRIu64"] ",
+                     1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
+                     tm.tm_hour, tm.tm_min, tm.tm_sec, nsec / 1000000);
         break;
 
     case TSM_BOOT:
diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h
index 3eb5b63..2703454 100644
--- a/xen/include/xen/time.h
+++ b/xen/include/xen/time.h
@@ -48,7 +48,7 @@ struct tm {
     int     tm_isdst;       /* daylight saving time */
 };
 struct tm gmtime(unsigned long t);
-struct tm wallclock_time(void);
+struct tm wallclock_time(uint64_t *ns);
 
 #define SYSTEM_TIME_HZ  1000000000ULL
 #define NOW()           ((s_time_t)get_s_time())
-- 
1.7.10.4

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

[Ian Campbell]

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.

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

[Andrew Cooper]

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.  Furthermore, the precision issue has been addressed, at
the expense of extra length, space wise.

Finally, Jan has expressed interest in not having timestamps at all.


Clearly there is disagreement as to what the best option is, and any
reduction is going to leave someone unhappy.

Pragmatically, the 'date' and 'datems' can be merged to make one fewer
options to choose from, but beyond that is going to be difficult.

~Andrew

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

[David Vrabel]

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

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

[Andrew Cooper]

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.  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, and it is not as if
calculating/printing the timestamp is the fast part of using a serial
console.

~Andrew

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

[Ian Campbell]

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.

Are there examples of the various formats somewhere?

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

>  and it is not as if
> calculating/printing the timestamp is the fast part of using a serial
> console.
> 
> ~Andrew

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

[Andrew Cooper]

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.

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.

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

~Andrew

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

[Ian Campbell]

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?

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

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

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

[Andrew Cooper]

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

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

[Ian Campbell]

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.

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

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

[Don Slutz]

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

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

[Ian Campbell]

On Tue, 2014-03-11 at 11:06 +0000, David Vrabel wrote:
> Wallclock date/time timestamps may be better served by a klogd like
> logging daemon in dom0 (but such a daemon doesn't exist yet).

xenconsoled can be configured to log hypervisor logs to disk too,
although I'm not sure that it adds timestamps as it goes.

Ian.

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

[Andrew Cooper]

On 11/03/14 14:14, Ian Campbell wrote:
> On Tue, 2014-03-11 at 11:06 +0000, David Vrabel wrote:
>> Wallclock date/time timestamps may be better served by a klogd like
>> logging daemon in dom0 (but such a daemon doesn't exist yet).
> xenconsoled can be configured to log hypervisor logs to disk too,
> although I'm not sure that it adds timestamps as it goes.
>
> Ian.
>
>

And furthermore is destructive to the Xen console ring, so you cant peak
with `xl dmesg`, or indeed use the replay debugkey.

~Andrew

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

[Ian Campbell]

On Tue, 2014-03-11 at 14:30 +0000, Andrew Cooper wrote:
> On 11/03/14 14:14, Ian Campbell wrote:
> > On Tue, 2014-03-11 at 11:06 +0000, David Vrabel wrote:
> >> Wallclock date/time timestamps may be better served by a klogd like
> >> logging daemon in dom0 (but such a daemon doesn't exist yet).
> > xenconsoled can be configured to log hypervisor logs to disk too,
> > although I'm not sure that it adds timestamps as it goes.
> >
> > Ian.
> >
> >
> 
> And furthermore is destructive to the Xen console ring, so you cant peak
> with `xl dmesg`, or indeed use the replay debugkey.

Easy: s,xl dmesg,less /var/log/xen/hypervisor.log,

Ian.

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

[Don Slutz]

On 03/11/14 10:14, Ian Campbell wrote:
> On Tue, 2014-03-11 at 11:06 +0000, David Vrabel wrote:
>> Wallclock date/time timestamps may be better served by a klogd like
>> logging daemon in dom0 (but such a daemon doesn't exist yet).
> xenconsoled can be configured to log hypervisor logs to disk too,
> although I'm not sure that it adds timestamps as it goes.

Currently it does not add time stamps.
    -Don Slutz

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

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

[Sander Eikelenboom]

Tuesday, March 11, 2014, 11:55:14 AM, you 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.  Furthermore, the precision issue has been addressed, at
> the expense of extra length, space wise.

I do like the existing format for one reason:
To be able to correlate log entries from syslogs for dom0 and domU to xl dmesg output.
(Guest dmesg is already a pain since it's timestamp is since guest boot and
doesn't correlate with anything easily)

> Finally, Jan has expressed interest in not having timestamps at all.


> Clearly there is disagreement as to what the best option is, and any
> reduction is going to leave someone unhappy.

> Pragmatically, the 'date' and 'datems' can be merged to make one fewer
> options to choose from, but beyond that is going to be difficult.

> ~Andrew

Re: [PATCH v5 0/5] Improvements to console timestamps

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 1187 bytes --]

On Fri, Mar 7, 2014 at 5:27 PM, Andrew Cooper <andrew.cooper3@citrix.com>wrote:

> This series aims to improve on the current implementation of console
> timestamps in Xen.
>
> Patch 1 is just movement of wallclock_time()s declaration to common code.
>
> Patch 2 changes Xen's idea of when time starts, from when the BSPs TSC was
> 0,
> to when Xen boots.
>
> Patch 3 guesses at AP time calibration earlier during boot, so printk()s
> using
> the new console timestamp have a real stamp, rather than 0s.
>
> Patch 4 is the meat of the series, adding a new timestamp implementation to
> printk_start_of_line().
>
> Patch 5 comes as a intermediate suggestion, to retain the old timestamp
> style,
> but to display milliseconds as well.
>

Acked-by: Keir Fraser <keir@xen.org>


> Finally, from discussion in the office, it has been suggested that the
> timestamp mode/format would be better as build-time configuration rather
> than
> boot-time configuration.  I am on the fence with this regard, but
> comments/thoughts are very welcome.
>
> ~Andrew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 1865 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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