On Wed, 14 Jan 2004, David Brownell wrote: > > Now a more interesting item, not yet entirely certain: > > > > struct usb_device->serialize will become a read-write semaphore. > > This is probably the right thing. Do we need it soon though? > > We're still stabilizing that part of usbcore. It wasn't clear > to me that anything currently under discussion _needed_ this > particular change, especially as we shift responsibility for > grabbing that lock higher in the stack. I'd kind of like to > avoid changing locking models along with those other updates.
On the other hand, serialize currently isn't used much outside the core. That's bound to change. If we are going to alter the lock, maybe sooner would be better. Although like I said, nobody seems to be certain that we really do need to alter it. (I find the argument about drivers for different interfaces in the same device needing simultaneous read access fairly convincing.) > > In general, a driver can acquire the serialize semaphore whenever it wants > > to block one of the functions above temporarily. A good example would be > > when calling usb_ifnum_to_if(); that function scans the interfaces in the > > current configuration and the results would be meaningless if the > > configuration unexpectedly changed. > > Alternatively, just rely on the fact that from the instant your driver > is probe()ed for an interface, you can rely on the fact that it'll be > valid until that driver (a) fails probing, or (b) returns from disconnect. > > That's effectively a readlock policy. The only device driver it fails > for would be usbfs ... since it doesn't use "front-door" access to the > device tree, from probe(). And it's how drivers already expect things > to work. (These changes _should_ be internal to usbcore!) > > Only drivers committing sins like holding on to interface handles after > disconnect() would even have to think about that lock ... and that means > usbfs will, since it's got to scan interfaces without probe() being used. You're right. Normal drivers should never have to worry about the config changing out from under them. But they might want to block disconnect() or notify_reset() at certain times. Oliver seems to think that's better done using a private semaphore rather than serialize. What do you think? Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
