Date:        17 Feb 2000 17:02:28 -0800
    From:        cgd@netbsd.org (Chris G. Demetriou)
    Message-ID:  <87hff7b9wb.fsf@redmail.netbsd.org>

  | to print a single "fooM at barN: information here" line, part of
  | that's printed by the generic autoconfig code, part is printed by the
  | parent bus code, part by the child device code.

But all in one thread, right?

I haven't looked at the kernel thread code at all, but I assume it has
state per thread.   Would it not be possible to create a "have the console"
thread variable, init it to false, and a global "console is grabbed" (also
init to false) and then in the low(ish) level console output routines, sleep
(pause the thread) before sending a character if the console is grabbed, and
it isn't this thread that has the console.   If the console isn't grabbed,
then grab it (set both global, and local vars to true) and continue.
Immediately after sending a newline sequence, release the console (and
wake any threads that were waiting).

I think this allows all the work to be done in the printf (or lower)
routines, and so doesn't require doing anything to the thousands of
printfs scattered throughout the kernel, and in particular, doesn't
require a printf to know if it is intended to appear at the beginning of
a line or not.

printfs from interrupt context will need special handling (the code needs to 
be able to determine it is running from an interrupt, and ignore the
locking protocol) - but they've always come out at any random place (and
they're supposed to be rare, as a printf takes a long time to execute,
and isn't a good thing to do in an interrupt context unless you really have to).

panic() could unilaterally release the console before starting its printf
just so things don't get messy - as could anything similar (traps into ddb
etc).

kre