> > > 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. > > They need not be confused.
I was trying to be polite. Think of it as a case of right hand working to undo what the left hand accomplishes. That's never going to be correct. It's at least "wrongly designed". > They are usually forced by external > circumstances, especially the network drivers. > All USB drivers need to unlink synchronously at least in disconnect. Not true. They can all unlink asynchronously in disconnect(); that's what usbnet does. (To minimize the time to unlink several queued URBs, someday when bulk queuing is more reliable than the last time I tested). And in any case, it's easy enough to record that you started to unlink an URB. > > 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. > > Does this have to be visible to the drivers ? I don't think so, but I'd probably just add a new URB flag kept with transfer_flags (like TIMEOUT_KILLED) so it might end up being visible. - Dave . _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
