From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: [RFC PATCH v2 0/5] Improvements to console timestamps Date: Fri, 28 Feb 2014 18:56:59 +0000 Message-ID: <1393613824-13230-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Xen-devel Cc: Andrew Cooper List-Id: xen-devel@lists.xenproject.org This series aims to improve on the current implementation of console timestamps in Xen. Patch 1 is a plain optimisation fix and logically independent from the rest of the series. 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. There is still one bug to fix; The time step when the platform timer start: (XEN) [ 1.069271] ENABLING IO-APIC IRQs (XEN) [ 1.073308] -> Using new ACK method (XEN) [ 1.077771] ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) [ 0.017017] Platform timer is 14.318MHz HPET (XEN) [ 0.021701] Allocated console ring of 16 KiB. Also, 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, and I would have to lean towards agreeing with this. Furthermore, 3 different timestamp modes would seem to be overkill. Comments welcome, ~Andrew