On Wed, 3 Mar 2004, David Brownell wrote: > No ... only the "unlink-during-submit" (ENOMSG) case made a > commitment to a complete() callback, the other returns didn't. > > 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. > > And after all, wasn't it you (and Oliver) who badgered me > into making sure those "normal" submit errors (no memory, no > bandwidth, etc) were never reported through completions? > Yet here you're arguing that they should be ... :) > > > It's important to keep the driver-visible semantics simple > and testable ... avoidable complications just make for cases > where USB drivers (and HCDs) _will_ get this wrong (and hence > have bugs). The docs I quoted before define semantics that > are simple, easily understood, and easily tested.
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. 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. 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. 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. 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 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 :-) Anyway, people who try to unlink an URB while it's being submitted deserve what they get! :-) 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
