> > Or in other words, if the guard is against unloading the completion
> > handler, which is a part of the driver, the code to do it cannot be in
> > the completion handler.
> > It has to be in another module or must be under the big kernel lock.
>
> I'd been more thinking about having the disconnect() not race against
> the completion handler, but I do see this other point.
>
> BKL is not a realistic option here. Which would leave this as some usbcore
> role, except that it doesn't explicitly know which module makes each
> request.
It could be included into usb_unlink_urb() which is called under BKL
from disconnect().
> One possible solution: submit urbs to a "struct usb_interface *" (and
> endpoint), and update that structure so that it's bound to current device
> configurations. We already believe that it needs mem_flags ... the old API
> could be a wrapper around this new/preferred API. Then the "hcd.c" layer
> could do something like call __MOD_INC_USE_COUNT(intf->driver->owner) when
> an URB is
> submitted (a handful of instructions), __MOD_DEC_USE_COUNT(owner)
> when the completion function returns.
Sorry, no.
This would break horribly for drivers which use the method of providing
a function pointer to the module subsystem to check for unloadability.
I am afraid there has to be an explicit method of waiting.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
