On Mon, 2 Aug 2004, Duncan Sands wrote:
> After the storm, silence... Does this mean that everyone is now happy with these
> patches? That's hard to believe...
My impression was that people would be happy to have nothing more than the
part that drops the lock after issuing an URB and reacquires it later.
> > in that case the urb fails, that's all. If you drop the lock before the urb is
> > submitted, it might get sent to the wrong endpoint. Consider the following:
> > (A) you drop the lock
> > (B) someone calls usb_set_configuration
> > (C) you submit the urb
> > If the new configuration happens to have an endpoint with the same pipe
> > as the one you are sending to, won't the urb be sent to it?
>
> Can someone please confirm that this problem really exists? If so, it is really
> a problem with the way the core handles things. My sparkling new start_wait_urb
> is just a work-around for it (there may be other problems it avoids too, the whole
> thing is a can of worms). Probably urbs should take a pointer to a (reference
> counted) interface, and not a pipe.
There is indeed a problem, but it's not solved so easily.
Consider this instead:
(A) User process uses libusb or /proc/bus/usb/devices or whatever
to determine what the configuration is and what interfaces exist.
(B) Someone else changes the configuration.
(C) The first process submits an URB to one of the old endpoints.
You can see that once (B) has happened it's already too late to fix
things, and this is _before_ you have even received the ioctl for (C)!
Since configuration changes can happen at any time, and there's no way for
usbfs to notify a user process that a change has occurred, there's no way
to fix this problem. Not in the current framework.
Perhaps usbfs could be changed to require that users claim an interface
before submitting an URBs and that users indicate the interface at the
time the URB is submitted. Then usbfs could invalidate all claimed
interfaces when a config change occurs and fail further submissions to any
of their endpoints. This would clearly require changes to libusb and
maybe even to user programs.
Alan Stern
-------------------------------------------------------
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
