From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v5 5/5] xen/console: Traditional console timestamps including milliseconds Date: Tue, 11 Mar 2014 14:04:11 -0400 Message-ID: <531F501B.70401@terremark.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> <531EEB92.2000802@citrix.com> <531EEE41.5080607@citrix.com> <531EEE9B.7030003@citrix.com> <1394546082.30915.11.camel@kazak.uk.xensource.com> <531F1768.2030008@citrix.com> <1394547519.30915.27.camel@kazak.uk.xensource.com> <531F2440.1050003@citrix.com> <1394550505.30915.48.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1394550505.30915.48.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 , Andrew Cooper Cc: Keir Fraser , Tim Deegan , Xen-devel , Stefano Stabellini , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 >>>>>>>>>> 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. >>>>> 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