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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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