Hi,
> The point I was raising is that once khubd starts its cleanup, only
> one activity makes sense: unlinking urbs. But today, it's _also_
Correct, so we want the core to do that, don't we?
> possible to continue submitting urbs. That can create some exotic
> failure modes, worth IMO getting rid of -- I've seen drivers cause
> them, they're a waste of time to debug rather than just prevent.
Definitely, if we can find a way to do so.
> Think of it as a proof-by-induction that shutdown will work. When
> there's a point past which no more activities can be started (like
> when device state becomes GONE), and existing activities all get
> canceled, shutdown will clearly work. With no such point, the exotic
> failure modes can prevent shutdown from working.
Correct, but incomplete.
You see, the full transition on unplugging is twofold from
WORKING to GONE to <NONE AT ALL>. The last state is caused
by kfree on the device descriptor. Preventing submission in the second
state is no problem. That's not the case for the last state unfortunately.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
