From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 15:40:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E09216A41F for ; Thu, 27 Oct 2005 15:40:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE3A343D46 for ; Thu, 27 Oct 2005 15:40:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9RFcYO1042598; Thu, 27 Oct 2005 09:38:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 27 Oct 2005 09:38:33 -0600 (MDT) Message-Id: <20051027.093833.114360961.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <4360DD7B.20900@samsco.org> References: <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 27 Oct 2005 09:38:41 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 15:40:28 -0000 In message: <4360DD7B.20900@samsco.org> Scott Long writes: : Dinesh Nair wrote: : > : > carrying on this discussion, what would be a good locking mechanism to : > use to protect tsleep() and other sensitive areas in a driver in freebsd : > 4.x ? : > : > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with : > some parts even being protected by mtx_lock(&Giant). : > : > would the use of simple_lock() or s_lock() do, given that : > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? : > : > the mechanism is actually a pseudo device driver which communicates with : > the real device driver. the pseudo device driver creates a bunch of : > /dev/ devices which the userland reads/writes to, and the pseudo device : > driver then places data in a few buffers. : > : > the real device driver then reads these buffers and uses busdma to send : > the data to the device. reading is done by using busdma to read from the : > device and then placing the data in these buffers for the pseudo device : > to return to the userland process. : > : > locking in the real device driver uses splhigh/splx, but what locking : > should be used in the pseudo device driver ? : > : : If you need to protect your pseudodriver from being interrupted by the : real driver then you'll need to use the same spl() as the driver. Note : that you shouldn't be using splhigh() unless you really know what you : are doing. Other than that, there likely isn't anything that you need : to do for 'locking' in 4.x. The kernel is non-reentrant there, so you : don't need to worry about synchronizing multiple threads. One thing to also bear in mind is that in 4.x spl locking is a code lock. It keeps multiple 'threads' of execution from entering a block of code. mutexes in -current are data locks. While usually one can think of the two the same, it can trip the unweary up. Locking in 4.x is indeed much simpler. Warner