[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 08 Oct 2012 19:31:40 +0100
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>
  • Delivery-date: Mon, 08 Oct 2012 18:32:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: Ac2lgyhbHBZxfqihB0u1/+C0BJiNkA==
  • Thread-topic: [PATCH 0 of 3] Introduce more debugging flexibility with ASSERT() macros

On 08/10/2012 19:16, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx> wrote:

> The following three patches introduce several debugging macros I have
> been using for a long time while debugging issues in Xen.
> ASSERT_PRINK() is hopefully obvious, and ASSERT_RUN() is useful when
> more complicated printing is required.

Are these going to get enough use to be worthwhile, rather than open-coding
them where necessary? In many places we may not care about being able to
disable the check-and-crash, so avoiding ifdefs is not necessarily a good

 -- Keir

> The final macro ASSERT_RUN_SINGLE() is not fit for upstream yet.  It is
> designed to force all other PCPUs into a wait loop in an NMI context, so
> the ASSERT()'ing processor can walk data structures without locks, and
> without fear that values are changing under its feet.  I will work on
> integrating this into the crash code (as it has a similar setup for the
> start of the kexec_crash() path), and upstream when I have time.
> ~Andrew

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.