From owner-freebsd-current@FreeBSD.ORG Tue Dec 2 05:57:46 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F42316A4CF for ; Tue, 2 Dec 2003 05:57:46 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68A1F43FD7 for ; Tue, 2 Dec 2003 05:57:40 -0800 (PST) (envelope-from freebsd-current@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARB22-0005nI-00 for ; Tue, 02 Dec 2003 14:57:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARB1z-0005nA-00 for ; Tue, 02 Dec 2003 14:57:35 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARB1z-0002ow-00 for ; Tue, 02 Dec 2003 14:57:35 +0100 From: Jesse Guardiani Date: Tue, 02 Dec 2003 08:57:35 -0500 Organization: WingNET Lines: 31 Message-ID: References: <20031201142022.GK8404@elvis.mu.org> <20031201193837.GD49341@cnd.mcgill.ca> <20031201230259.GL8404@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org User-Agent: KNode/0.7.2 X-Mail-Copies-To: never Sender: news Subject: Re: 5.2-BETA dsp.c duplicate lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jesse@wingnet.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2003 13:57:46 -0000 Maxime Henrion wrote: > Mathew Kanner wrote: > [patch ripped] >> >> Maxime, >> I think it would be better to isolate the changes (DUP_OK flag >> and lock creation) to just the channel code, no need to touch every >> driver. > > Yes, but to do this I'd need either to make the channel code use > mtx_init() directly, which would defeat the purpose of the USING_MUTEX > define, or to completely unifdef -U it. Since I had no idea if this code > was actually used or not, I went the safe way and just changed the > snd_mtxcreate() wrapper interface to accept mutex options. For what it's > worth, there is at least one direct invokation of mtx_init() in the sound > drivers, so it seems this define is actually already broken. > > This needs to be sorted out before committing this patch if we need to, > but for now, I just wanted to see if using MTX_DUPOK solved the problem or > not. I'll try to test later today. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net