On Wed, Oct 21, 2009 at 06:02:35PM +0200, Oliver Neukum wrote: > Am Mittwoch, 21. Oktober 2009 17:44:25 schrieb Alan Stern: > > On Wed, 21 Oct 2009, Oliver Neukum wrote: > > > Am Mittwoch, 21. Oktober 2009 16:10:57 schrieb Alan Stern: > > > > On Wed, 21 Oct 2009, Oliver Neukum wrote: > > > > > Very well, here are just a few ideas unfortunately involving layering > > > > > violations. Something about storage makes me want to violate > > > > > layering. > > > > > > > > > > 1. Introduce a heuristics to detect endangered devices > > > > > > > > > > I think we can be pretty sure that all devices that drop their caches > > > > > have the following features: > > > > > - bus powered > > > > > - draw >100 mA > > > > > > > > > > So I propose that we don't autosuspend them during normal operations > > > > > and, later on, tell the SCSI layer that these devices need a cache > > > > > flush during a normal suspension. > > > > > > > > As far as I know, there is no way to tell the SCSI layer. (Besides, it > > > > should already know which devices need cache flushes.) > > > > > > OK, so why don't we take the hint from the SCSI layer? > > > > Layering makes it very awkward. Have you looked at sd_suspend() in > > drivers/scsi/sd.c? > > We need to get at scsi_disk and it is the gold standard. To me, it seems that the problem is that we're approaching this backwards.... We're trying to get a low-level driver to determine if the upper-levels are done with a physical device so we can autosuspend. No matter what we come up with, we're never going to get it right; consider what would happen if a userspace application was messing with a /dev/sgX node arbitrarily. What we need to do is turn this around. The upper layers need to signal the lower layers when it is safe to autosuspend. For example, consider a device with a mounted filesystem. The filesystem needs to flush dirty buffers and then signal that it's in a "safe" state. The block layers need to pass that through to sd_mod, which in turn needs to write the data, do a cache flush, spin-down the disk, and signal to SCSI core that it is "safe" for autosuspend. SCSI core then passes that on to the HCD, which in this case is usb-storage. If you open a /dev/sgX node, then sg_mod signals via SCSI core that the underlying device is unsafe for suspend. This is probably some sort of reference counter type thing. An "advanced" use app such as HAL could use an ioctl to make sg_mod signal that it is safe to suspend the device, if all it's doing is a periodic check for media. I guess this just reminds me of some debates we had a few years ago about how the code figures out how much data there is to transfer. We had a pile of heuristics and lookup tables which constantly caused problems. The right answer there was to make the upper layers explicitly signal what they wanted. Just like that case, here the only modules which have all the knowledge to make an informed decision are the upper layer modules. Matt -- Matthew Dharm Home: mdharm-usb@xxxxxxxxxxxxxxxxxx Maintainer, Linux USB Mass Storage Driver I want my GPFs!!! -- Stef User Friendly, 11/9/1998
Attachment:
pgp2jLrZbxSj0.pgp
Description: PGP signature
