Hi,
   I thought a while ago that it would be nice to standardize DPRINTF and
DPRINTFN, and now that we have a <sys/debug.h> I've been pondering how we
could integrate them, and make it easier to generate debug output. These
are my thoughts so far:

1. Add a keyword specification to config(5)

	debug <attribute> [<level>]

   where <attribute> is the attribute that gets a file included, such as a
   device name or system module such as "bluetooth", and <level> is the
   default debug level for that attribute.

2. config(1) will, when it sees this in a config file, do the following:

  a. add the following to a generated debug.c:

	int debug_<attribute> = <level?=0>;
	sysctl_createv(clog, 0, NULL, NULL,
		CTLFLAG_PERMANENT | CTLFLAG_READWRITE,
		CTLTYPE_INT, "<attribute>",
		SYSCTL_DESCR("<attribute> debug level"),
		NULL, 0,
		&debug_<attribute>, sizeof(debug_<attribute>),
		CTL_DEBUG, CTL_CREATE, CTL_EOL);

  b. add the following (or equivalent?) to the generated Makefile, for
     files included by the attribute:

	COPTS.<file>+="-DDEBUG=debug_<attribute>"

3. <sys/debug.h> contains something like:

	#ifdef DEBUG
	extern int DEBUG;
	#define DPRINTF(fmt, args...)	do {			\
		if ((DEBUG) > 0)				\
			printf("%s: "fmt, __func__ , ##args);	\
	} while (/* CONSTCOND */0)

	#define DPRINTFN(n, fmt, args...)	do {		\
		if ((DEBUG) > (n))				\
			printf("%s: "fmt, __func__ , ##args);	\
	} while (/* CONSTCOND */0)
	#else
	#define DPRINTF(...)
	#define DPRINTFN(...)
	#endif

4. add debug.9 detailing this, and a general guide to how much information
should be produced for different levels.


Potential hurdles that I can think of:

- DEBUG is already a known keyword, I would have to look at how extensive
  the usage was, maybe this should use DPRINT instead.

- some files are not part of any 'module', so it would be difficult to
  apply this to them. a magic attribute could solve this, or allow
  to specify 'debug <file>'

- there could be an issue with debugging colliding attributes, but I'm
  not sure how much a problem that would be in reality.

is this desireable?
any other comments before I look at implementation?

iain