Am Mittwoch, 9. Oktober 2002 20:30 schrieb John Tyner:
> 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. :)

Giving up? What is that? Can one eat it? How does it taste?

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

Yes.

[..]
> 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

Yes, right. A V4L device is different from a normal char device.
I had forgotten. Sorry.

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

Please elaborate.

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

Much better.
There's only one issue left. The control messages.

There must be no control messages running after the disconnect handler
has finished. The brute force approach is taking the mutex around them.
Outside probe and disconnect that is. They are already protected.

        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

Reply via email to