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. > > Are you the same Oliver who always claims that correctness is more > > important than style? If not, what have you done with him? :-) > > I am the same. I just have the decency to shoot the cow cleanly > instead of dismembering it ;-) > That is to say, let's shelve it for 2.7. Agreed. > > No, no! That's the whole point. The reference counting in the driver > > model is based on the idea that you send a notification to a driver > > telling it to stop using something, but it's allowed to continue using (or > > trying to use) it until it notifies you back. That's why we have both > > device_del() and a release() callback, for example. > > Sorry. Maybe that's a linguistic problem. Let me be clearer. > > Reference counting controls deallocation. In addition there's a state where > the connection between data structure and device is severed, meaning that > all io to it will cleanly fail. So far with me? > By "not reusing" I meant that there must be no way from the 'undead' state > back to functional. Once a data structure is in that state the reference > counter cannot be increased and the connection will never be reestablished. > If the physical device is still present a new data structure must be allocated. Okay, I agree with you. James Bottomley would disagree partially; according to him it's okay to increase the reference counter while in the "undead" state because (1) such things will happen only rarely as the window is rather short, (2) all attempted I/O in this state will fail anyhow, and (3) it's not worth the effort to prevent it. > > > Nothing prevents giving out 'struct usb_endpoint_binding's which URBs > > > could be addressed to. They could have proper reference counting. > > > You could have them on lists which you walk in case of disconnect(), > > > config change, etc ... > > > > That is just what David has proposed for 2.7. We should give some extra > > thought to the problem of dealing with ep 0, however. > > David is right. It seems to me that there's a problem with ep0 only if > we do reference counting on some internal representation of the device. > That would only shift the problem. We should actually allocate a data > structure with every binding which can be refcounted and io addressed to. 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 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. 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
