mtx_lock_do_what_i_mean()

Marcel Moolenaar xcllnt at mac.com
Wed Aug 26 06:57:12 UTC 2009


On Aug 25, 2009, at 11:35 PM, Bruce Evans wrote:

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

That's a non sequitur. Sharing travel destinations does
not mean that you travel together, for example.

The fact that currently the console is used by both does
not mean there's coupling. In fact, the debugger goes
through the low-level console interface, whereas printf()
gets redirected eventually to go through the TTY layer.
Having printf() not even write to the console does not
mean that the debugger cannot keep using the low-level
console interfaces...

-- 
Marcel Moolenaar
xcllnt at mac.com





More information about the freebsd-arch mailing list