Hi,
you make me feel like a villain from a bad movie, but ...
> I think it would allow, but the problem seems to be that the disconnect
> routine cannot wait indefinitely for a wake up call from the release
> function. Unfortunately, as Oliver pointed out, a user opening the
> device and not releasing it for ages is valid.
>
> I've tried to solve it in the following manner:
>
> release {
> get disconnect mutex
> decrement users
Don't do this. Release does not map to close.
You have no users if release is called.
> if ( !users and camera is disconnected ) {
> free memory
> return
> }
> release disconnect mutex
> }
>
> In the event that users is zero and the camera is gone, we free the
> memory and don't release the mutex. 1) The mutex has been kfreed, and 2)
> We know that disconnect has already completed because _we_ hold the lock
> (see below), so there is no need to relase the mutex.
>
> disconnect {
> get disconnect mutex
> mark camera as unplugged
> ...
> unregister device
> if ( !users ) {
> free memory
> } else {
> release disconnect mutex
> }
> }
>
> Again if the memory is freed, we don't touch the mutex.
>
> How does this look?
There's a small problem still with this approach.
You have to have mutual exclusion with open too. So open takes
the mutex. Therefore you must not kfree it. If you use one common
semaphore for the whole driver, it works. That semaphore you have
to up again unconditionally of course.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
