Date: Wed, 26 Aug 2009 16:35:31 +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: <20090826161941.B41435@delplex.bde.org> In-Reply-To: <C6553051-E797-47EA-9044-7ED91F469F51@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>
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 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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090826161941.B41435>