On Mon, 12 Jul 2010, Oliver Neukum wrote: > Am Montag, 12. Juli 2010, 04:02:58 schrieb Alan Stern: > > On Sun, 11 Jul 2010, Oliver Neukum wrote: > > > > > I am afraid this is not quite the case. If the device was just opened and closed, > > > the normal heuristics make sense. If the device reports that no medium is present, > > > you should suspend at once. > > > > In theory, yes. But how many programs continue to hold the device file > > open after they learn that no medium is present? And do so without > > sending more transfer requests? > > None that I know of. But do they need to? It seems to me that the normal > polling will continously open/close devices are a rate comparable to the > standard time the heuristics uses. That statement is a little unclear. Do you mean that the normal polling programs will open the device file (which automatically sends a TEST UNIT READY command) and then close the device file each time they poll for media present? I think that's right; as far as I know they do not hold the device file open between polls. (If any of them do, they ought to be changed.) I don't see how it affects the topic of this discussion, though. It means that suspending whenever you learn there is no media will yield essentially the same result as suspending whenever the device file is closed. As for the time required... I have thought several times that perhaps we should have an "autosuspend_ms" attribute in addition to (if not instead of) the "autosuspend" file. While delays much shorter than 50 or 100 ms don't make any sense, that still leaves a lot of room between 50 and 1000 ms, which is the shortest we can currently accomodate. > Now we could shift this to user space, Shift what to user space? > but I doubt we'd get it in > in a reasonable time frame. And I believe this is a feature we could > use in the long run. Do you mean we could use autosuspend for storage devices in general, or that we could use autosuspend whenever no media is present? > > Besides, you surely must agree that this patch is a tremendous layering > > violation. If we really want to allow autosuspend under the > > circumstances just described, the right place to do it is in the SCSI > > disk driver. > > You are obviously right. I'd say the code makes sense but it is in > the wrong place. It wouldn't take too much work to enhance the patches I have already submitted to make them autosuspend when no media is present, even while the device file is open. However I don't think this would improve the end result significantly. 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
