Date: Mon, 30 Apr 2007 15:41:22 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Daniel Eischen <deischen@freebsd.org>, Attilio Rao <attilio@freebsd.org>, freebsd-arch@freebsd.org, Hans Petter Selasky <hselasky@freebsd.org>, Julian Elischer <julian@elischer.org> Subject: Re: msleep() on recursivly locked mutexes Message-ID: <200704301541.23678.jhb@freebsd.org> In-Reply-To: <200704272032.20664.hselasky@freebsd.org> References: <200704262136.33196.hselasky@c2i.net> <46323A77.8010907@elischer.org> <200704272032.20664.hselasky@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704301541.23678.jhb>