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