Date: Tue, 25 Aug 2009 11:58:21 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Ed Schouten <ed@80386.nl> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: mtx_lock_do_what_i_mean() Message-ID: <C6553051-E797-47EA-9044-7ED91F469F51@mac.com> In-Reply-To: <20090825073057.GK2829@hoeg.nl> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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... FYI, -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6553051-E797-47EA-9044-7ED91F469F51>