[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 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 >>>>>>>> no-op. >>>>>>> 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 >>>>>>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |