Date: Wed, 26 Aug 2009 22:06:20 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Ed Schouten <ed@80386.nl>, FreeBSD Arch <arch@freebsd.org> Subject: Re: mtx_lock_do_what_i_mean() Message-ID: <20090826192646.O10848@besplex.bde.org> In-Reply-To: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <C6553051-E797-47EA-9044-7ED91F469F51@mac.com> <20090826161941.B41435@delplex.bde.org> <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090826192646.O10848>