From owner-freebsd-arch@FreeBSD.ORG Wed Aug 26 06:57:12 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 066B01065693 for ; Wed, 26 Aug 2009 06:57:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id E71D28FC21 for ; Wed, 26 Aug 2009 06:57:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from [172.24.241.157] (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOZ00MTP1ZANQ30@asmtp028.mac.com> for arch@FreeBSD.org; Tue, 25 Aug 2009 23:57:11 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090826161941.B41435@delplex.bde.org> Date: Tue, 25 Aug 2009 23:57:09 -0700 Message-id: <6B5F99F6-3A66-4AE3-89BE-973F40AE34A9@mac.com> References: <20090824174050.GI2829@hoeg.nl> <2678DC6C-3E91-420A-B43D-02E0F1F853C5@mac.com> <20090825073057.GK2829@hoeg.nl> <20090826161941.B41435@delplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1074) Cc: Ed Schouten , FreeBSD Arch Subject: Re: mtx_lock_do_what_i_mean() X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 06:57:12 -0000 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 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@mac.com