dprintk() and gdprintk() to be compiled out when NDEBUG

dprintk() and gdprintk() to be compiled out when NDEBUG

[Jan Beulich]

All,

I'd like to propose to honor the 'd' in these functions' names (which
I understand to mean "debug") in that such functions should be
no-ops in non-debug builds. I'd then be inclined to introduce a
gprintk() automatically adding XENLOG_GUEST and the printing of
current using the %pv format. Quite likely the (mis-)use of these
two functions may then temporarily result in messages not meant
to be debugging ones to become hidden in non-debug builds. If
others agree, I'd try to make one pass through the tree to try to
identify such, but I'd like to ask others to also keep an eye on that
aspect.

Jan

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Andrew Cooper]

On 11/02/15 07:50, Jan Beulich wrote:
> All,
>
> I'd like to propose to honor the 'd' in these functions' names (which
> I understand to mean "debug") in that such functions should be
> no-ops in non-debug builds. I'd then be inclined to introduce a
> gprintk() automatically adding XENLOG_GUEST and the printing of
> current using the %pv format. Quite likely the (mis-)use of these
> two functions may then temporarily result in messages not meant
> to be debugging ones to become hidden in non-debug builds. If
> others agree, I'd try to make one pass through the tree to try to
> identify such, but I'd like to ask others to also keep an eye on that
> aspect.

I agree.  I suspect many of the existing gdprintk()s will need to turn
into dprintk()s.

~Andrew

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Jan Beulich]

>>> On 11.02.15 at 11:05, <andrew.cooper3@citrix.com> wrote:
> On 11/02/15 07:50, Jan Beulich wrote:
>> I'd like to propose to honor the 'd' in these functions' names (which
>> I understand to mean "debug") in that such functions should be
>> no-ops in non-debug builds. I'd then be inclined to introduce a
>> gprintk() automatically adding XENLOG_GUEST and the printing of
>> current using the %pv format. Quite likely the (mis-)use of these
>> two functions may then temporarily result in messages not meant
>> to be debugging ones to become hidden in non-debug builds. If
>> others agree, I'd try to make one pass through the tree to try to
>> identify such, but I'd like to ask others to also keep an eye on that
>> aspect.
> 
> I agree.  I suspect many of the existing gdprintk()s will need to turn
> into dprintk()s.

Maybe, but that's yet another topic (unless you meant gprintk()s
instead of dprintk()s).

Jan

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Andrew Cooper]

On 11/02/15 10:32, Jan Beulich wrote:
>>>> On 11.02.15 at 11:05, <andrew.cooper3@citrix.com> wrote:
>> On 11/02/15 07:50, Jan Beulich wrote:
>>> I'd like to propose to honor the 'd' in these functions' names (which
>>> I understand to mean "debug") in that such functions should be
>>> no-ops in non-debug builds. I'd then be inclined to introduce a
>>> gprintk() automatically adding XENLOG_GUEST and the printing of
>>> current using the %pv format. Quite likely the (mis-)use of these
>>> two functions may then temporarily result in messages not meant
>>> to be debugging ones to become hidden in non-debug builds. If
>>> others agree, I'd try to make one pass through the tree to try to
>>> identify such, but I'd like to ask others to also keep an eye on that
>>> aspect.
>> I agree.  I suspect many of the existing gdprintk()s will need to turn
>> into dprintk()s.
> Maybe, but that's yet another topic (unless you meant gprintk()s
> instead of dprintk()s).

I did mean gprintk().  Sorry.

~Andrew

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Ian Campbell]

On Wed, 2015-02-11 at 07:50 +0000, Jan Beulich wrote:
> All,
> 
> I'd like to propose to honor the 'd' in these functions' names (which
> I understand to mean "debug") in that such functions should be
> no-ops in non-debug builds. I'd then be inclined to introduce a
> gprintk() automatically adding XENLOG_GUEST and the printing of
> current using the %pv format.

Sounds fine to me.

>  Quite likely the (mis-)use of these
> two functions may then temporarily result in messages not meant
> to be debugging ones to become hidden in non-debug builds. If
> others agree, I'd try to make one pass through the tree to try to
> identify such,

Thanks, that would be useful I think. Will you cover arch/arm too?

> but I'd like to ask others to also keep an eye on that aspect.

I'll certainly try.

Ian.

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Jan Beulich]

>>> On 18.02.15 at 11:58, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2015-02-11 at 07:50 +0000, Jan Beulich wrote:
>>  Quite likely the (mis-)use of these
>> two functions may then temporarily result in messages not meant
>> to be debugging ones to become hidden in non-debug builds. If
>> others agree, I'd try to make one pass through the tree to try to
>> identify such,
> 
> Thanks, that would be useful I think. Will you cover arch/arm too?

I did the patch and the auditing pass already, and I skipped - as
you kind of expected - arch/arm. Since we're not under pressure
and everyone should be doing debug builds right now anyway, I
don't think applying the to-be-posted patch without ARM
adjustments will do much harm; let me know if you think otherwise.

Jan

Re: dprintk() and gdprintk() to be compiled out when NDEBUG

[Ian Campbell]

On Wed, 2015-02-18 at 11:05 +0000, Jan Beulich wrote:
> >>> On 18.02.15 at 11:58, <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2015-02-11 at 07:50 +0000, Jan Beulich wrote:
> >>  Quite likely the (mis-)use of these
> >> two functions may then temporarily result in messages not meant
> >> to be debugging ones to become hidden in non-debug builds. If
> >> others agree, I'd try to make one pass through the tree to try to
> >> identify such,
> > 
> > Thanks, that would be useful I think. Will you cover arch/arm too?
> 
> I did the patch and the auditing pass already, and I skipped - as
> you kind of expected - arch/arm. Since we're not under pressure
> and everyone should be doing debug builds right now anyway, I
> don't think applying the to-be-posted patch without ARM
> adjustments will do much harm; let me know if you think otherwise.

No problem, please go ahead and I'll try and find a moment to audit the
ARM ones separately.

Ian.