From owner-freebsd-current@FreeBSD.ORG Tue Sep 20 04:51:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 EEA3516A41F for ; Tue, 20 Sep 2005 04:51:23 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DC343D45 for ; Tue, 20 Sep 2005 04:51:22 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so156122nzk for ; Mon, 19 Sep 2005 21:51:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ezAqreclplPY1nHbSNDJsXMwblEgT2EVtLudNMFEP0MIa686TubH8K+5XPxXx62mUplT1zIRAqG2Mno6gBDcHQtP48LCMMuz8p1rqP/aPJ25Lxn21LyYb2nhpROWzEOhznKzIAXa1NPcxpg1bO8FtlSiBjAUZxEDQknNovQy0X8= Received: by 10.37.21.12 with SMTP id y12mr3621851nzi; Mon, 19 Sep 2005 21:51:22 -0700 (PDT) Received: from michelle.rndsoft.co.kr ( [211.32.202.211]) by mx.gmail.com with ESMTP id 19sm5989616nzp.2005.09.19.21.51.20; Mon, 19 Sep 2005 21:51:22 -0700 (PDT) Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j8K4p5Hn002841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2005 13:51:05 +0900 (KST) (envelope-from yongari@gmail.com) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j8K4osI3002839; Tue, 20 Sep 2005 13:50:54 +0900 (KST) (envelope-from yongari@gmail.com) Date: Tue, 20 Sep 2005 13:50:54 +0900 From: Pyun YongHyeon To: Alexander Leidinger Message-ID: <20050920045054.GA754@rndsoft.co.kr> References: <20050912044212.GC5182@rndsoft.co.kr> <47d0403c05091122276fd0a231@mail.gmail.com> <20050913070149.GE9481@rndsoft.co.kr> <47d0403c0509131235ed58122@mail.gmail.com> <20050914014830.GA13631@rndsoft.co.kr> <20050915033848.2d87da42.skywizard@MyBSD.org.my> <20050915014509.GA17602@rndsoft.co.kr> <20050915114653.431f17c5.skywizard@MyBSD.org.my> <20050915043448.GB18332@rndsoft.co.kr> <20050915113354.iv5u8ycfksscw4wk@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050915113354.iv5u8ycfksscw4wk@netchild.homeip.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Ariff Abdullah Subject: Re: documenting the locking requirements? (was: Re: panic upon kldunload snd_ich (lor # 159)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2005 04:51:24 -0000 On Thu, Sep 15, 2005 at 11:33:54AM +0200, Alexander Leidinger wrote: > Pyun YongHyeon wrote: > > >> I tend to agree with you. Since that sndstat_busy() isn't enough, how > >> about we acquire the entire sndstat so nobody can monkey with it (as the > >> proposed / attached diff) and at the same time avoiding this LOR > >> message. It seems much better rather than locking sndstat after > >> sndstat_busy() and much of pcm_unregister() procedures, only to find out > >> that somebody acquire it within that moment. > >> > > > >I didn't try the patch but it looks good to me. :-) > >If you have more time would you please fix race in sndstat_open()? > > > >Minor note : I think it is better to use sx_xunlock ranther than > >sx_unlock as sx_xunlock clearly indicates which type of locks held. > > Are the locking requirements (what needs to be locked and why/when, in which > order) in the sound code documented somewhere? If yes: where? If no: can I > convince you (either one or both of "you") to write something up (plain text > would be enough for a start)? > Sorry for the late reply. AFAIK there is no such documentation. :-( I'm still learning sound subsystem and it's hard to understand internal workings of our code(I lost my track while reading vchan support code). And I agree with you. It would be great to have a documentation for sound subsystem including locking/interfaces etc. Though there is a simple documentation for sound subsystem in architecture handbook, it's not much help understanding internal workings. Personally, I think the locking in sound subsystem is not perfect. We may need to redefine what locking order should be maintained or which locks(driver lock, codec lock, pcm lock, play/record/vchannel lock, mixer lock etc) are needed. If we have midi code in sound subsystem we would have one more lock. I have no idea we really need all these locks. Maybe Ariff have better idea/understanding than me. -- Regards, Pyun YongHyeon