Re: Dealing with debugging macros for printing as part of aprint clean-up

[Izaak <yitzhak%inbox.ru@localhost>]

On Mon, Feb 16, 2015 at 06:02:03PM +0000, Christos Zoulas wrote:
> In article <20150214201740.GA2426%norite.fritz.box@localhost>,
> Izaak  <yitzhak%inbox.ru@localhost> wrote:
> >On Sat, Feb 14, 2015 at 10:25:59AM -0500, Christos Zoulas wrote:
> >> On Feb 14,  4:05pm, mrg%eterna.com.au@localhost (matthew green) wrote:
> >> -- Subject: re: Dealing with debugging macros for printing as part of aprint 
> >> | changing from DPRINTF() to aprint_debug*() will likely change
> >> | the semantics.  these debug messages will now trigger with
> >> | "boot -x", instead of a DEBUG kernel, won't they?
> [...]
> Not a problem, things are complicated enough so we all get them wrong
> sometimes. Another way would be to introduce ADPRINTF, but this sounds
> like we are going overboard with complexity and combinations.
That could balloon quickly -- BDPRINTF, CDPRINTF, etc. Those files
mostly redefine their own version of DPRINTF as well, so it might even help
to somehow centralize that functionality by moving it into the main printing
routines, but I am not sure.

> >So, if I find instances where DPRINTF is only used in autoconfiguration
> >and nowhere else, then I will do as you say and change the printf inside
> >the DPRINTF, otherwise I will just leave it alone for now. Still, this
> >issue will come up again in the second part of the project because all of
> >those other printfs inside macros will need to be converted.
> 
> Perhaps fixing the DPRINTF's that deal with autoconf to aprint_debug is
> the way to go after all... But that introduces code bloat?
I am not sure how that introduces code bloat -- it is a simple exchange
of calls -- but I only have superficial knowledge of the situation. If
core developers make a decision, then I will go with it.

-- 
Izaak