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

[Keir Fraser <keir.xen@gmail.com>]

On 08/10/2012 19:16, "Andrew Cooper" <andrew.cooper3@citrix.com> 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
argument.

 -- 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