> > 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.
>
> Oh, you mean the "can_unload" module function?
> That seems pretty obscure. What uses it, other
> than IPV6? (Which hardly even uses it...)
Nothing else I know of as yet.
> > Your solution with the usage counters would work, but only for drivers
> > which use the usage count.
>
> That is, for all drivers that exist today ... which would make it
> a good start, I'd say.
If the question weren't an all purpose API, I'd happily agree.
Your solution is less flexible than we could wish for.
In addition IMHO we should not assume that manipulating
the usage count of modules that actually don't use it, is safe.
The module code is planned to change a lot.
> > 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.
>
> I provided a sketch of an API, which solves the problem which
> had so far been identified. It was obviously incomplete. You
> start to trash it, not improving it, not providing anything better,
> and allude to "other races" (without identifying them) as if
> they should have been addressed too.
>
> Why might I find that interaction ... unsatisfying? counterproductive?
What I failed to properly explain, was a strictly conventional scheme.
driver in the disconnect case:
usb_submit_urb() - something else - disconnect() -> usb_unlink_urb() ->
wait_for_complete() -> kfree() -> ready to unload
usbcore:
usb_submit_urb() -> join waitqueue -> give urb to HCD
HCD:
hardware finished -> call completion handler -> wake_up()
In this scheme wait_for_complete() could be implemented extremely
conventionally and could be useful to the drivers not only during
disconnect.
A driver could implement a scheme like this for everything but disconnect
as we have discussed. But if we have to find a solution anyway, we might as
well implement the most flexible scheme, don't you think ?
A possible usage for this you might find in the disconnect of the auerswald
driver. There's a very interresting race on disconnect. The completion
handler submits another urb.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
