I took a closer look at your "sketch" diffs, and it looks like what you
wanted to do is mostly eliminate the output of boot/autoconfig, and for
embedded applications, that makes sense.

To be entirely clear, yes, I was suggesting that we change all the printfs
in the kernel into "log" calls, and solve this problem the "right" way. I'd
argue that we should re-examine what might be better termed "the kernel
notification system" if we want to do this right.

I'd take a clue from modern syslog(3) and suggest that we need two pieces
of meta-information with each message - what subsystem it came from
(driver, fs, network, scheduler, vm, however you want to divvy up the
sections of the kernel), and what "priority" or "severity" it is (debug,
info, warning, error, death-destruction-mayhem).

With that additional information, you can make a disposition decision in
the "log" (or whatever you want to call it) routine, where "disposition"
could be "put to log" (RAM buffer, log file, or socket), "put to console",
"send SNMP trap", etc.

I'd say that the existence of the "log" routine in subr_prf.c was a step in
that direction which wasn't followed through by CSRG or its contributors,
probably because of the sheer number of printf's & panics that would have
had to change. Fortunately, the prospect of a wholesale roto-till of the
kernel has never slowed down (let alone stopped) the NetBSD project...

Properly done, this might obviate the need for hacks like "xconsole" and
the UCONSOLE kernel option.

The old model of UNIX said, "you have a console display with a human
operator monitoring it who will deal with system notifications." I'd say
it's long past time to generalize kernel notifications to support more than
just that one model of reporting.

	comments?

	Erik <fair@clock.org>