Re: documenting the locking requirements? (was: Re: panic upon kldunload snd_ich (lor # 159))

On Thu, Sep 15, 2005 at 11:33:54AM +0200, Alexander Leidinger wrote:
 > Pyun YongHyeon <pyunyh_at_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