On Wed, 9 Oct 2002, Oliver Neukum wrote:

> Hi,
>
> you make me feel like a villain from a bad movie, but ...

Ha, ha, ha. Hopefully, you won't give up before I get it right. :)

> > release {
> >     get disconnect mutex
> >     decrement users
>
> Don't do this. Release does not map to close.
> You have no users if release is called.

Alright, so then the camera has two states as far as being open. Open
turns it on, and release turns it off. Right?

> > disconnect {
> >     get disconnect mutex
> >     mark camera as unplugged
> >     ...
> >     unregister device
> >     if ( !users ) {
> >             free memory
> >     } else {
> >             release disconnect mutex
> >     }
> > }
>
> 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.

I don't think in this case I need to worry about open. The videodev lock
is held across both an open call and during a video_unregister_device
call. Therefore, it isn't possible for my open to be executing at the same
time as any code after the unregister call in disconnect. Either
disconnect waits for open to finish, or disconnect proceeds and further
opens are not possible.

So, then we only need to consider the race between disconnect and release
trying to free the memory. If disconnect gets there, and there are no
users, memory is freed, no problem. If there are users, then disconnect
needs some way to signal release that it is done and release can now free
the memory.

Perhaps here, we can reverse my earlier try and put the wait_event into
the release call.

disconnect marks the camera as gone. if there are no users, memory is
freed, if there are users, disconnect marks itself as having completed.

release tests if the camera is gone and there are no more users, if true,
then it waits for disconnect to finish and then frees the memory.

Any better?

I really appreciate you guys' help.

Thanks,
John



-------------------------------------------------------
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

Reply via email to