On Tue, 29 Sep 2009, Oliver Neukum wrote: > 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 >:-> Yes. But that is true also if the user simply unplugs the device before closing the device file. A "sync" call can easily be added to a userspace program. It's not appropriate within a kernel API. > > 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. Unfortunately there's no way to tell whether a device is mass-storage or not. Even devices using usb-storage don't have to be block structured -- they can be things like SCSI printers. > Or recognize that this exports a port's feature, which is usually > done through usbfs. I don't regard "usually" as a persuasive argument. Furthermore, this API applies only to ports with an attached device, which means it is better described as a device API than as a port API. As an analogy, consider the suspend port feature. We export that through sysfs. > [..] > > > 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 don't understand what you're getting at. The semantics are clear: The device's port is disabled, the device is logically disconnected, and the port is kept disabled until a connect change occurs. If you think it would be a good idea, I could add that the device is unconfigured before these things happen. > To do so cleanly needs a new callback, which is not native to USB. Again, I don't understand. 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
