> This lock should not see much contention. It will be held only very
> briefly in any path where a state gets changed. Something like this:
>
> spin_lock_irq(&global_state_lock);
> if (usbdev->state != USB_STATE_NOTATTACHED)
> usbdev->state = USB_STATE_CONFIGURED;
> else
> notattached = 1;
> spin_unlock_irq(&global_state_lock);
> if (notattached) ...
Ehm. You have to check the state in usb_submit_urb().
[..]
> > > Now a more interesting item, not yet entirely certain:
> > >
> > > struct usb_device->serialize will become a read-write semaphore.
> >
> > Why? I don't see the benefit of this. We want to reduce the contention
> > on this lock, not make it bigger. And read-write locks are generally a
> > bad thing, and should be avoided as much as possible...
>
> I don't see how making it a read-write semaphore would increase
> contention. If anything it should _lower_ contention, since several
> readers could hold it at once rather than being forced to wait for each
> other.
>
> And remember, this is an rw _semaphore_, not a spinlock. While rw
> spinlocks can have problems, I understand that semaphores are generally
> much better behaved, at least in some implementations.
>
> However, nobody seems to be certain that we really need to change this
> (except possibly Duncan Sands).
The only reason to go for an rw-semaphore is contention. If contention is
low, there's no point in going for the extra overhead of such a lock.
[..]
> Anyway, why complain that drivers would need the semaphore only on very
> rare occasions if you're so worried about reducing contention? :-)
Global spinlocks also cause cacheline bouncing.
> > I'm all for fixing bugs in the existing usbfs. But I think that's
> > basically beating a dead horse into a prettier lump of goo. We really
> > need to start over and make usbfs2. It should look something like the
> > gadgetfs interface.
>
> What about backward compatibility?
Supposed to be on libusb level.
> > Because of all of this, please don't do this now. It's a big change,
> > one that should be held off till 2.7 to try to do (if you really want to
> > then.)
>
> I'm happy to leave usbdev->serialize as a regular semaphore. We should
> still require that it be held by callers of all the routines in the list
> above, though.
>
>
> > > Some longer-range changes:
> > >
> > > Add a new usb_device_state: USB_STATE_RESET. Although it
> > > doesn't correspond exactly to any state given in the USB spec
> > > it could be very useful. A device is in this state while it
> > > or a hub upstream from it is undergoing a reset.
> > >
> > > The somewhat obscure reason for having this is that it allows us to
> > > recover the devices attached to a hub when that hub is reset. Resetting a
> > > hub disables all its ports; after the hub revives, each of its children
> > > will have undergone the equivalent of a reset. Knowing that this has
> > > happened, we will be able to retain the child device structures and their
> > > driver bindings. They will resume activity rather than going through the
> > > process of logical disconnect followed by logical connect -- which would
> > > have the effect of replacing each device with a new incarnation, breaking
> > > things like filesystem mounts.
> >
> > But as the device did just loose power, and then get it back again, it's
> > the only sane thing to do. We have to drop the whole device and
> > initialize it again. Think of downloading firmware to devices.
>
> As I mentioned in a previous message, for mass storage devices we do not
> want to go through the disconnect() - probe() sequence. For other devices
> it may not matter so much, so long as they know about the reset and can
> reinitialize the device.
Any device that keeps state depending on syscalls cares.
[..]
> Ah -- we do it when the device is unplugged. So far as I can see, we
> don't do it when usb_deregister() is called. Nor do we set the interfaces
Nor must we ever do this, unless it's in the interval between unbinding
and reprobe. But from a viewpoint of correctness a blockages that exists
only for an arbitrarily low amount of time doesn't exist at all.
Regards
Oliver
-------------------------------------------------------
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
