On Mon, 19 Apr 2004, Oliver Neukum wrote: > Am Montag, 19. April 2004 04:55 schrieb Alan Stern: > > On Sun, 18 Apr 2004, Oliver Neukum wrote: > > > Am Sonntag, 18. April 2004 16:36 schrieb Alan Stern: > > > > > A spinlock could replace it. But that is a small detail. > > > > > > > > Yes it could. Then the driver would start to resemble its original > > > > form again, defeating Greg's point. > > > > > > Where's the difference between > > > lock_kernel(); > > > vs. > > > spin_lock(&skel_open_lock); > > > > Ah, but if you use a spinlock (or semaphore) instead of lock_kernel() then > > you have to lock _both_ the open() and disconnect() routines. Otherwise > > the lock won't do anything useful. > > That's an advantage. Using the knowledge that sys_open() takes BKL in > an example driver is not nice.
Yes, of course. The point is that after you put the lock and unlock statements in several places, the driver looks a lot like it did before Greg's changes. > [..] > > What I mean is that once a driver is no longer bound to an interface it > > ought to be prevented from doing I/O to ep0 as well -- even though other > > drivers bound to other interfaces might still be allowed to use ep0. In > > Right. > > > other words, URBs should be addressed to an interface-endpoint pair. For > > endpoints other than ep0 this doesn't matter, since such eps only belong > > to a single interface, but with ep0 it does matter. > > No, you are repeating the old error on a new level. > You cannot tell from an interface-endpoint whether the submission is legal > or not. The binding of an interface to a driver can change an arbitrary > number of times, even rebinding to the same driver is legal. > > You need to record the binding somewhere and use it during submission. > I see two options to allow that. > 1. You really make a new data structure like usb_driver_binding > 2. You record it in the URB meaning changes to usb_alloc_urb() I was being too imprecise. What I mean is, yes, we should have something like a refcounted data structure that refers to an individual endpoint in an individual interface, and URBs should be submitted for one of these structures. But ep0 still needs special treatment. We could, for example, add one of these data structures for ep0 to _each_ interface, in addition to having a special one that doesn't belong to any interface and is used for overall device management (like SET_CONFIGURATION URBs). Or maybe a little simpler, submit URBs for the refcounted interface structures -- no need to specify the endpoint since that's already recorded in the pipe member. We'd need some way to submit URBs for ep0 independent of any interface, though. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
