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

[matthew green <mrg%eterna.com.au@localhost>]

Christos Zoulas writes:
> In article <20150213211112.GA52%norite.fritz.box@localhost>,
> Izaak  <yitzhak%inbox.ru@localhost> wrote:
> >On Fri, Feb 13, 2015 at 05:17:24PM +0000, Christos Zoulas wrote:
> >> In article <20150208103806.GA1632%norite.fritz.box@localhost>, Izaak
> >> <yitzhak%inbox.ru@localhost> wrote:
> >> > Having read through many files, I have found that often printf is
> >> > wrapped in a macro like 'DPRINTF', which is occasionally used both in
> >> > the driver attachment function and also elsewhere in the file. I am
> >> > not sure whether to [...] suppose this question holds also for
> >> > general macro usage, so what is the best way to deal with that?
> >> 
> >> I think it is best to leave them alone too for now...
> >I think that specifically for autoconfiguration it would be better to
> >replace the debugging wrapper macro with the aprint_debug and
> >aprint_debug_dev for attachment and then leave the macro in place for
> >the rest of the file. I am only suggesting it because I have seen this
> >in a few places already, so I am afraid if I leave it then the clean-up
> >will leave behind many printf occurrences -- of course, those would be
> >fixed in part 2 of the project anyway though. What do you think of that
> >instead?
> 
> Perhaps it is best to just change the printfs to aprint_debug_dev, but
> leave the other printf flavors (tprintf uprintf) alone? This at least
> will not change behavior?

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


.mrg.