On Mon, Feb 16, 2015 at 06:02:03PM +0000, Christos Zoulas wrote: > In article <[email protected]>, > Izaak <[email protected]> wrote: > >On Sat, Feb 14, 2015 at 10:25:59AM -0500, Christos Zoulas wrote: > >> On Feb 14, 4:05pm, [email protected] (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
