From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v5 5/5] xen/console: Traditional console timestamps including milliseconds Date: Tue, 11 Mar 2014 10:55:14 +0000 Message-ID: <531EEB92.2000802@citrix.com> References: <1394213285-9359-1-git-send-email-andrew.cooper3@citrix.com> <1394213285-9359-6-git-send-email-andrew.cooper3@citrix.com> <1394532785.18366.10.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394532785.18366.10.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , Tim Deegan , Keir Fraser , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org 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 >> Signed-off-by: Andrew Cooper >> CC: Keir Fraser >> CC: Jan Beulich >> CC: Ian Campbell >> CC: Stefano Stabellini >> CC: Tim Deegan >> >> --- >> >> The change in arm is only for the sake of compilation - the function is a >> no-op. > Acked-by: Ian Campbell > >> 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