Hi Greg, > So? It's safe to hold a semaphore while copying data from or to > userspace. I don't really see that this will fix much, becides make it > harder to figure out where the lock is held :)
I agree that it's not clear that it gains anything (see this thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=108229756532478&w=2). I did it in my tree planning to do some benchmarks, but when the proc_bulk, proc_control issue came up I decided to dump the whole thing on you and see what you would say :) > > 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. > > Hm, I don't see how this fixes anything. If we hold the semaphore, the > urb will complete eventually, and then the semaphore will be released, > and any one blocking on it will wake up, right? But no-one else can do anything while you're waiting... Remember that this is a per-device semaphore, so you can't (for example) use usbfs to talk with another interface while waiting for the bulk or control message to complete. That could take quite some time, I'm talking several seconds here. Also, this semaphore is shared with the core. The core also doesn't want to have to wait several seconds for an urb to time out. > > 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. > > Why? See above. > > 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. > > Why do you want to make the waiting interruptible? What will that help > with? It lets me hit ctrl-c when urbs start timing out. Ciao, Duncan. ------------------------------------------------------- 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
