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

[christos%astron.com@localhost (Christos Zoulas)]

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?
>> | 
>> | that might be OK -- autoconf messages shouldn't happen normally,
>> | unlike other debug messages..
>> 
>> I meant change the printf's inside DPRINTF() to aprint_debug*() but
>> leave the DPRINTF(). Sorry I was not clear.
>Sorry, I did not completely realize the implication of my suggestion -- I
>am a beginner. If I do it your way though, then I run into the original
>problem that I presented -- i.e. in a few places there is shared printf
>through DPRINTF being used in both autoconfiguration and elsewhere in the
>driver, which should be split into aprint* and log*.

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.

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

christos