On Feb 14, 4:05pm, [email protected] (matthew green) wrote: -- Subject: re: Dealing with debugging macros for printing as part of aprint
| | Christos Zoulas writes: | > In article <[email protected]>, | > Izaak <[email protected]> wrote: | > >On Fri, Feb 13, 2015 at 05:17:24PM +0000, Christos Zoulas wrote: | > >> In article <[email protected]>, Izaak | > >> <[email protected]> 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.. I meant change the printf's inside DPRINTF() to aprint_debug*() but leave the DPRINTF(). Sorry I was not clear. christos
