mtx_lock_do_what_i_mean()

[Bruce Evans]

On Tue, 25 Aug 2009, Marcel Moolenaar wrote:

> On Aug 25, 2009, at 12:30 AM, Ed Schouten wrote:
>
>> * Marcel Moolenaar <xcllnt at mac.com> wrote:
>>> I would approach the problem differently: decouple printf() in the
>>> kernel from anything to which we have a TTY attached. Instead, look
>>> at printf() as a means to write to the message buffer only. Echoing
>>> things that go into the message buffer to the console becomes 1)
>>> optional (yay!), and 2) something you can do by going through the TTY
>>> layer (use a kthread or use a process [syslog]).
>> 
>> Yeah. That would be a lot better, but that means you still need to have
>> a lot of code to make it work properly w.r.t. kernel panics:
>
> The debugger doesn't call printf(). It calls db_printf(). We
> already have everything in place to decouple the debugger
> from the problem and I would definitely not pull it in. The
> debugger is a problem all by itself...

Everything is in place to remove 0.1% of the coupling.  Debugger i/o
still normally goes to the same device as user and kernel i/o, so it
is strongly coupled.

Bruce