On Thu, 29 Jul 2004 18:19:15 +0200 Duncan Sands <[EMAIL PROTECTED]> wrote:
> Patches 16/18 and 17/18 (proc_control and proc_bulk) also > release the semaphore while waiting for the urb to complete. > This fixes http://bugme.osdl.org/show_bug.cgi?id=3108. You > may well wonder why I copied some of the usb_start_wait_urb > infrastructure from messages.c. Good question! There are two > reasons that I recall. The first is that if you use usb_start_wait_urb, > then you are obliged to drop the semaphore before calling it. > But the device might get disconnected, or the configuration may > change, between your dropping the semaphore and the actual > urb submission in usb_start_wait_urb. That's probably not the > end of the world, but I'd rather avoid those kinds of hassles. > Another reason is that I'd like to see if I can make the waiting > interruptible. Having the waiting logic in devio.c means (hopefully) > that I can muck around with it without borking the rest of the USB > subsystem. So, what does happen if a disconnect happens while your sparkling new static start_wait_urb sits in wait_for_completion()? How exactly is this different? The patch attached to OSDL 3108 does not look good to me. The right approach would be to do usb_dev_get to prevent disconnect from pulling things from under you, then submit URBs. -- Pete ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
