From owner-freebsd-arch@FreeBSD.ORG Mon Apr 30 21:00:40 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C29FA16A401; Mon, 30 Apr 2007 21:00:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 65F3213C483; Mon, 30 Apr 2007 21:00:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3UL0Xpr016564; Mon, 30 Apr 2007 17:00:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 30 Apr 2007 15:41:22 -0400 User-Agent: KMail/1.9.6 References: <200704262136.33196.hselasky@c2i.net> <46323A77.8010907@elischer.org> <200704272032.20664.hselasky@freebsd.org> In-Reply-To: <200704272032.20664.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704301541.23678.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 30 Apr 2007 17:00:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3184/Mon Apr 30 09:51:57 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel Eischen , Attilio Rao , freebsd-arch@freebsd.org, Hans Petter Selasky , Julian Elischer Subject: Re: msleep() on recursivly locked mutexes 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: Mon, 30 Apr 2007 21:00:40 -0000 On Friday 27 April 2007 02:32:20 pm Hans Petter Selasky wrote: > > > P0 unlock(1); > > > P0 unlock(2); > > > > this looks "interesting". > > Can you give a more concrete example of this? > > what work is done in the upcall? WHo is upcalling to who? > > For example an USB device driver might be up-calling to the USB host > controller driver. Down call is when the transfer finishes. I think in this case you don't want to keep the periph locked while you ask the controller to process requests. Instead, the periph drivers should queue requests to the controller and receive replies, but they should be considered as two independent objects. For example, network drivers drop their lock when passing a packet (request) up the stack. -- John Baldwin