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

[Iain Hibbert <plunky%ogmig.net@localhost>]

On Sun, 15 Feb 2015, Izaak wrote:

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

my personal opinion is that DPRINTFs should not be converted to
aprint_debug(), as they are not produced in normal operation, and as
largely the output would make no sense in the normal case of things.. for
example, from a driver I wrote (dev/usb/uhso.c), in the attach routine
there is

	DPRINTF(1, ": sc = %p, self=%p", sc, self);

which (when UHSO_DEBUG was defined) is just going to spit out the function
name and pointer values if uhso_debug >= 1, so that I as a developer can
track the routines being called in context. The chances are that even I as
the developer of this routine don't want to see it unless I'm tracking
down a bug. For this, it is often normal to enter ddb to set the value, or
personally I prefer just adding a sysctl so that I can tweak the debug
level, and debug output can become immense at higher levels.

This type of DPRINTF is very common. They were for the original developer,
or someone who needs to track down an obscure runtime bug. Rebuilding with
options UHSO_DEBUG is really not a problem for that case, but if they were
enabled by boot -x then the dmesg output would get very long very quickly,
and usually only a specific device needs to be debugged.

it doesn't even make sense to me to change this to use log(9), because
often it is hoped that a message will just hit the dmesg buffer and be
available after a crash. Sure, once the driver is stable you can perhaps
rely on something handling a log() message..

at the very least, leave all the DPRINTFs until later

iain