Hi Dave,
This makes me count three patches, which (seems to me) should be merged in about this order: ...
patch 3 (the other usbfs changes) should come before all others. The reason is that (1) if the first two patches go in, then usbfs becomes unusable until patch 3 goes in, and (2) if patch 3 goes in first, it improves the usbfs situation (with no regressions) even though the first two patches are needed for it to really work OK.
Are you sure of that? Sounds to me like the patch #1 really can't affect usbfs stability at all. But your usbfs changes (#3) and the "delete usb_interface.driver" patch (#2) are at least slightly inter-dependent, so they need to be merged at roughly the same time.
Given that, I still like the idea of merging those usbfs updates last, to match the layering in usbcore.
Patches 1 and 2 are likely to have more problems getting
past the Greg Filter...
I'd hope #1 wouldn't, those would all be NOPs until #2 is merged.
But Greg's "wait for 2.7, then backport" suggestion does make some trouble. If 2.7 were under way I'd concur; but since it isn't, I suspect changes other than actually deleting usb_interface.driver should be sorted out so they can (safely) be merged sooner than that.
PS: I don't like this comment change:
* This can be used by drivers to release an interface without waiting ... + * for their disconnect() methods to be called. In most cases this also + * causes the driver disconnect() method to be called. *
"In most cases" is too vague. What is someone who needs to rely on having disconnect() called supposed to think? How about this:
What are they supposed to do? Use the source to answer detailed questions; use testing and code review to to improve quality.
* This can be used by drivers to release an interface without waiting * for their disconnect() methods to be called. It causes disconnect * to be called, except possibly when used from a probe() method.
But that's not the only case when it wouldn't be called. My own experience in specifying APIs suggests to me rather strongly that these oddball cases aren't worth nailing down in natural language at this time.
- Dave
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
