On Fri, Mar 30, 2007 at 06:08:44PM +0200, Oliver Neukum wrote: > Am Freitag, 30. M?rz 2007 17:41 schrieb Greg KH: > > On Fri, Mar 30, 2007 at 11:17:28AM +0200, Oliver Neukum wrote: > > > > However it would not always work out so nicely. > > > Have a look at this code from usblp: > > > > > > timeout = USBLP_WRITE_TIMEOUT; > > > > > > rv = wait_event_interruptible_timeout(usblp->wait, > > > usblp->wcomplete || !usblp->present , timeout); > > > if (rv < 0) > > > return writecount ? writecount : -EINTR; > > > > Well, usblp incorrectly (in my opinion) tries to return the status of > > every urb to userspace. I'm still not quite sure why it needs to do > > that, and we can't just throw a ton of urbs at the device and then walk > > away. It's not like userspace does much if we report an error on the > > exact packet that fails, vs a packet later on, right? > > I can't tell you whether cups closes the device for every job. > But it does not matter. Keeping it open is fully legitimate. You must > know which urb has failed to know whose print job has failed.
Ah, hm, good point, forgot about that :( > [..] > > I think it really comes down to the problem of checking the urb status > > flag. > > Only for the write case. Reading needs the transfer_buffer. > mdc800 has exactly that race. You are looking for a work around now. If you need the transfer_buffer then use a lock. > > I _REALLY_ want to get rid of that field and not have drivers us it at > > all. I would like to pass the value of the status flag to the urb > > callback directly, and only have the status field be used by the host > > controllers. > > Good idea in any case. > > > The last time I looked into implementing this, I think the UHCI driver > > had some 'issues' with how it would work, or maybe it was EHCI, sorry it > > was a few years ago. > > > > However, if we are able to fix that, and never let drivers touch that > > field, then the large majority of these kinds of problems will go away, > > right? > > I haven't counted them. I guess it is safe to say that many issues > would go away. So, would you possibly be willing to look into this if you have the chance? thanks, greg k-h ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
