The unlink succeeded, which means the submit must too ... since complete() never fires unless submit() succeeds (returns zero), and unlink() can't succeed unless complete() fires.
Okay, I'm confused.
You want to treat unlink-during-submit as a separate sort of error from the "normal" submit errors. The only reason is because it makes a commitment to a completion callback, and only reason for that commitment is because unlink_urb succeeded.
Not the "only" reason, but doing it that way does provide a nicely simple and consistent way to specify URB behavior: submit once, and it completes once (perhaps by cancelation).
What I was suggesting earlier is that things could be slightly different. If unlink_urb returned an error code of -ENOMSG, then there would be no
commitment to a completion callback. Hence submit_urb could follow the
"normal" error pathway and return -ENOMSG. This is in line with the API
semantics.
Except ... how would unlink() know to do that?
- It could of course always return some kind of error, but that would be neither useful nor testable.
Tests are just like any high-reliability driver: they need to know for sure that an operation succeeded or failed, with fault codes informative enough to specify a recovery action.
- It could add even more complexity to the unlink logic, in HCDs and usbcore; hence more ways to create bugs. It'd have to be able to detect that dequeue() failed, and then revert work it already did on the unlink. But hey, the HCD may already have given back the URB, that work can't be reverted...
As it stands, usbcore doesn't have a lot to do when unlinking; just mark the URB, kick the HCD in case it needs it, and then maybe do that annoying synchronous blocking. And the HCD has little to do too ... which is good, lots of races lurk there.
I don't like those two options as much as just succeeding. Much simpler all around.
You said this couldn't be done because the fact that the URB was linked
successfully was already been "advertised to the rest of the kernel". If
that's so with unlink-during-submit, why isn't it so with normal errors as
well? Is the advertisement merely the success of unlink_urb? Changing the success to a failure should mitigate your objection then.
The advertisement was unlink() succeeding, yes. But changing that would hit problems like those I mentioned above.
I would prefer _not_ to report normal errors via completions, ditto for unlink-during-submit. Even if it's not more work, it is more complicated.
Good!
Perhaps you don't like my scheme because of its peculiar implications? The submission failed because of the unlink request, but the unlink failed
because the submission didn't go through. I admit it's circular
No, it's mostly a testability and simplicity kind of thing.
reasoning, but with a new unique error code to explain what happened there shouldn't be any problems. (And if you read a lot of time-travel science fiction stories, you quickly get accustomed to this sort of thing :-)
Not time travel, no. But that does sound like some quantum games, as if "unlink" and "link" particles can't coexist unless Schroedinger's cat was dead when you asked, yet coexistence is proof that it now alive!
Anyway, people who try to unlink an URB while it's being submitted deserve what they get! :-)
I'd almost agree, except that not having a clean, simple answer in that case is what I call an API bug. And since I believe I see such an answer, I don't see a need to leave the bug there.
- Dave
Alan Stern
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
