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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 08/10/12 19:31, Keir Fraser wrote:
> 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

I hope that ASSERT_PRINTK() will start seeing quite a lot of use,
especially with compound conditional statements where is is impossible
from crash to see which of the individual conditionals failed.

ASSERT_RUN() perhaps not so, but having it available means one less
thing to opencode when debugging.


I had not considered the case for {WARN,BUG}_PRINTK() which have the
same argument as ASSERT_PRINTK().  Would you like to see them introduced
as well?

~Andrew

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

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com