On 14/01/2020 16:12, Jan Beulich wrote:
> On 14.01.2020 17:00, Jürgen Groß wrote:
>> On 14.01.20 16:47, Jan Beulich wrote:
>>> On 09.01.2020 14:48, Juergen Gross wrote:
>>>> --- a/xen/Kconfig.debug
>>>> +++ b/xen/Kconfig.debug
>>>> @@ -81,6 +81,12 @@ config PERF_ARRAYS
>>>> ---help---
>>>> Enables software performance counter array histograms.
>>>>
>>>> +config DEBUG_BUGVERBOSE
>>>> + bool "Verbose BUG_ON messages"
>>>> + default DEBUG
>>>> + ---help---
>>>> + In case a BUG_ON triggers additionally print the triggering
>>>> + condition on the console.
>>>>
>>>> config VERBOSE_DEBUG
>>> While I can see reasons to put this here, doing so means the option
>>> will be unavailable in non-EXPERT release builds. Is it intended to
>>> be that way?
>> I can move it either to xen/Kconfig or in Kconfig.debug out of the
>> "if expert" section if you want.
> I think this would be better, but give others a chance to voice
> opinions.
TBH, I don't think anyone will be interested in not having the strings.
The change is what? a couple of hundred bytes? That is a fraction of
the size of some functions we have.
Personally, I wouldn't even bother having the option.
>
>>>> --- a/xen/include/xen/lib.h
>>>> +++ b/xen/include/xen/lib.h
>>>> @@ -8,7 +8,12 @@
>>>> #include <xen/string.h>
>>>> #include <asm/bug.h>
>>>>
>>>> +#define BUG_ON_VERBOSE(p) do { if (unlikely(p)) BUG_VERBOSE(#p); } while
>>>> (0)
>>>> +#ifdef CONFIG_DEBUG_BUGVERBOSE
>>>> +#define BUG_ON(p) BUG_ON_VERBOSE(p)
>>> Looks like this will fail to build on Arm? Also - any particular
>> Uh, shame on me!
>>
>>> reason for the introduction of the separate BUG_ON_VERBOSE(),
>>> when BUG_ON() could directly use BUG_VERBOSE()? I don't think we
>>> want to encourage use of BUG_ON_VERBOSE() elsewhere ...
>> I wanted to offer that option. If you want me to remove it I wouldn't
>> mind.
> As above - unless there are good reasons (making others to agree
> with you to have it), I'd prefer to not see it being independently
> usable, at least for the time being.
I'd agree with the wish to not have a new flavour of BUG_ON().
People writing code aren't going to want the complexity of thinking
about it, and people who care about the presence/absence of messages
will care about it globally, not on a per-use bases.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
