Date: Tue, 20 Sep 2005 13:50:54 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-current@freebsd.org, Ariff Abdullah <skywizard@MyBSD.org.my> Subject: Re: documenting the locking requirements? (was: Re: panic upon kldunload snd_ich (lor # 159)) Message-ID: <20050920045054.GA754@rndsoft.co.kr> In-Reply-To: <20050915113354.iv5u8ycfksscw4wk@netchild.homeip.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 15, 2005 at 11:33:54AM +0200, Alexander Leidinger wrote: > Pyun YongHyeon <pyunyh@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050920045054.GA754>