From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 11:24:55 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 8726416A41F for ; Thu, 27 Oct 2005 11:24:55 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 4675A43D45 for ; Thu, 27 Oct 2005 11:24:53 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 90217 invoked by uid 0); 27 Oct 2005 11:24:51 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 27 Oct 2005 11:24:51 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9RBOUrf061036; Thu, 27 Oct 2005 19:24:30 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <4360B8EE.4070605@alphaque.com> Date: Thu, 27 Oct 2005 19:24:30 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> <200510261324.03790.jhb@freebsd.org> In-Reply-To: <200510261324.03790.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Scott Long Subject: locking in a device driver (was: use of bus_dmamap_sync) 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 11:24:55 -0000 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 ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+