Re: 5.2-BETA dsp.c duplicate lock

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.

> Also, if this is the right direction, we should back out the
> commit I did that re-ordered code that prevented duplicate channel
> locks (obviously it wasn't completen) channel.

If the code is not supposed to acquire several channel locks at once,
then yes, it's not the right direction to go.  As I said in my previous
mail, and that's why I wanted the advice of you sound guys, in that case
it's just a workaround. :-)

Cheers,
Maxime