> > > 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().
>
> From khubd disconnect() paths, maybe, but not the others. And
> of course, what happens when BKL finally vanishes? :) Plus, that
> wouldn't protect completions in other situations.
You are right. So how about doing it extremely conventionally ?
A waitqueue would work if it's woken from the HCD.
[..]
> > 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 can't follow this. The module system's core mechanism to test "is it
> unloadable" gets bypassed, yet you'd expect that somehow to work?
> While respecting that mechanism would not work???
The module subsystem provides _two_ entirely different APIs
for checking for unloadability. Either it checks for the module usage count
or it calls a function the module provides itself.
Thus a solution that requires by design that the usage count be used is
broken.
In addition the module subsystem is planed to undergo a modification
that makes usage of the module counters less attractive to drivers.
Your solution with the usage counters would work, but only for drivers
which use the usage count. Yet it does not address the other races with
completion which are solvable by the drivers itself, but should be addressed
by the core to simplify writing drivers.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
