mtx_lock_do_what_i_mean()

[Bruce Evans]

On Tue, 25 Aug 2009, Marcel Moolenaar wrote:

> 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 coupling here occurs at the destination.

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

printf() goes through the low-level console interface in the same way
as the debugger in most cases (unless the console has been redirected).

> Having printf() not even write to the console does not
> mean that the debugger cannot keep using the low-level
> console interfaces...

It just means that printf() would be slightly broken (no longer
synchronous, and unusable in panic()...).  It would remove only another
0.1% of the coupling for the low-level console interfaces, since the
debugger must keep using them, and the requirements for working with
debuggers are so strong that also working in other cases is trivial.

Note that strong coupling is simplest here.  If debugger i/o is in a
separate module then it has a hard time even knowing the interrupted
state.  One impossibly difficult weakly-coupled case is when normal
i/o is done by a propietary X driver using undocumented hardware
features from userland, with some undocumented features active at the
time of the interrupt.  Non-debugger console i/o is also impossibly
difficult in this case.  FreeBSD doesn't attempt to support it, and
uses cn*avail* interfaces to give null i/o and less than null ddb
support.  With all the i/o in the kernel, it is possible to guess the
hardware and driver state by peeking at driver variables and hardware
registers.  With strong coupling, it is possible to do this robustly.
Upper layers must cooperate by recording enough of their state in an
atomic way.  The coupling in lower layers then consists of using the
records and knowing that they are sufficient.

Bruce