> I've tried to solve it in the following manner:
> 
> release {
>       get disconnect mutex

I don't like the sound of "disconnect mutex" since it implies
a mutex that's not used everywhere it should be.  The driver
has its own device state; just protect all access to it.  Don't
ever try to get fancy about bypassing locks in special cases,
that just leads to trouble.  Maybe you should use a spinlock
for that purpose, instead of a binary semaphore; just make sure
you drop the spinlock before you do anything that'd block.

But you have the right idea:  make it so that

(a) you can know in the disconnect() code whether the device
     is in use (and have access to _every urb_ being used, so
     you can unlink all of them before returning!), doing a
     "final cleanup" only when there are no users and otherwise
     does only partial cleanup;

(b) your release() code notices it's the last close on a
     device that's been removed (dev == null), and if so it
     does the (deferred) "final cleanup";

(c) all other driver access fails -ENODEV for devices that
     have been removed (dev == null), even if they're in that
     "waiting for last close to do final cleanup" state.

I'm not sure why you'd need to wait for any other reason than
to ensure the previously-active urbs get unlinked.  It ought
to be easy to use a counting semaphore for this, though I've
not tried using the Linux primitives in that way.

Also, it's not strictly necessary to release mutexes you've
grabbed if they're being freed, but it's good style to do so.
Plus:  some lock debugging tools have been known to track and
warn about such issues, so it can be more than a style issue.

- Dave


>       decrement users
>       if ( !users and camera is disconnected ) {
>               free memory
>               return
>       }
>       release disconnect mutex
> }
> 
> ...





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