On Thu, 1 Oct 2009, Oliver Neukum wrote: > Am Mittwoch, 30. September 2009 00:07:25 schrieb Alan Stern: > > > I have no problem with exporting this feature at all. It is necessary for > > > what you want to do and what you want to do is useful. > > > My problem is with the API to user space. I suggest that you add this > > > to the storage driver not generic USB code and all is well. > > > > Do you mean _both_ storage drivers (usb-storage and ub)? What about > > future storage drivers (UASP)? You can see why I preferred to add it > > in the core... > > That's a factor. usbfs would still be better. Why do you think usbfs would be better than sysfs? As far as the kernel is concerned there's not much difference, but it makes things considerably harder for user programs. > > > You could even make an API that makes the storage driver unregister > > > the SCSI host but retain its binding to the device until it tells usbcore > > > to disable the port. That closes the race with probe(). > > > > There is no need to worry about races with probe, as far as usb-storage > > is concerned. Probe and unbind are already sufficiently mutually > > exclusive. I don't know about ub. > > You race between "safe unplug" and another probe. Yes, I see. So it would be best to have the code keep the device locked while doing an unconfigure followed by a port disable. > Putting the API into usbfs fixes this, as usbfs has a concept of claiming > a device. Making things even _more_ difficult for the user program... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
