With respect to new API entries to distinguish the synchronous and unsynchronous unlink cases:
> An asynchronous unlink due to being asynchronous allows other > things to happen while it is underway. Same thing for a synchronous unlink -- except the initiating thread can't cause them, it'll be blocking till the unlink is done. > Therefore the need to do > a synchronous unlink while an asynchronous unlink is happening > may arise. I think I see what you're suggesting, but I'd basically say what I've said before: drivers which are that confused about how they work are really asking for trouble! APIs that try to work with code that broken have a nasty problem: they foster even more broken code. For example, only one "it's unlinked!" callback will ever be seen, but if both synchronous and asynchronous unlinks of the same URB are both expected to succeed, it's unclear what urb->status should be used: -ECONNRESET or -ENOENT. (Frankly I think that there should only be one urb->status code for the unlink completion. The calling thread clearly knows which mode it's using, and that's sufficient.) > This would be vastly simnplified and could be pushed into the hcd layer > if the functions had seperate names. Still doesn't _require_ separate entry points for sync and async unlink. While there are some changes I'd like to see in the link/unlink behavior, they're more at the level of new flags saying whether the URB is linked to the hardware, and whether unlink has been requested. It's nasty to encode unlink state in urb->status, where it will sometimes obliterate _real_ transfer status. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
