> > > > 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.
The problem you described was how to prevent the module with the completion handler from getting unloaded ... a waitqueue (or <linux/completion.h> struct completion) would be one tool for one mechanism used to solve it. Apples and oranges. > [..] > > > 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. Oh, you mean the "can_unload" module function? That seems pretty obscure. What uses it, other than IPV6? (Which hardly even uses it...) > 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. > 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? - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
