Am Montag, 28. September 2009 22:03:28 schrieb Alan Stern: > On Mon, 28 Sep 2009, Oliver Neukum wrote: > > Am Montag, 28. September 2009 20:16:44 schrieb Alan Stern: > > > On Mon, 28 Sep 2009, Oliver Neukum wrote: > > > > Wouldn't it be better if the device were removed in a suspended state > > > > so buffers on storage devices could be flushed? > > > > > > That is a userspace detail. The intended mode of operation is that a > > > program like "eject" will first unmount all filesystems on the device > > > > Hm. The device may or may not have a filesystem on it. > > Well, if it doesn't have a filesystem then there's nothing to unmount! > > :-) Extremely true ;-). But there may be something to sync >:-> > In fact, the "remove" attribute works for any USB device, since all it > does is disable the upstream port. But normally it's intended only for > mass-storage devices. I was going to say that it's needed only for If it is intended only for some make it available only for them. Or recognize that this exports a port's feature, which is usually done through usbfs. [..] > > If this is the only way to correctly use the attribute why not make the > > attribute do what needs to be done to be correct? > > Because doing that requires a larger view of the whole system. The USB > layer doesn't know whether a device contains a mounted filesystem, or a > filesystem at all, or even whether it has an underlying block device. That is true. But you are adding a generic attribute. If it is to do something beyond exporting a mere port state, as it should according to its placement, you need to develop generic semantics, like what you do if a driver is still attached to an interface and what you do if other devices are further down in the device tree. We should most emphatically not add a generic interface for a special purpose. > I suppose the attribute could switch the device to configuration 0 > before disabling the port. That would cause the drivers to be unbound > safely, while communication was still possible. On the other hand, > userspace can do the same thing just as easily by writing "-1" to the > bConfigurationValue attribute -- which would remove the need to unbind > usb-storage explicitly. To do so cleanly needs a new callback, which is not native to USB. Regards Oliver -- 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
