Am Donnerstag 27 September 2007 schrieb Alan Stern: > On Thu, 27 Sep 2007, Oliver Neukum wrote: > > > > Oliver, I'm surprised at you! This patch is a big hack, not to mention > > > a layering violation and an inversion of the proper calling sequence. > > > > Well, > > > > 1. autosuspend should not be specific to USB > > Correct. Which means support for it should be added to the SCSI > drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a > way that basically ignores what the SCSI layer is doing. It isn't. The decision to autosuspend is based on activity on the bus. Now you might argue that the decision to do an autosuspend should always propagate upwards from the lowest level of the device tree. Then I ask why? > > 2. I like to view the generic SCSI code as a library > > That viewpoint might work out okay in some cases, but I don't think > it's tenable when dealing with high-level drivers like sd and sr. sg worries me. > > 3. The low level drivers will have to decide whether to suspend devices, > > as the generic code doesn't know whether the bus is shared. > > I'm having trouble understanding this; it's a bit ambiguous. Does > "devices" mean "SCSI devices", "host adapter devices", or both? Does SCSI devices > "generic code" refer to the SCSI core, the high-level SCSI drivers, or > something else? When you say the bus is "shared", do you mean there > are multiple SCSI devices attached to it or do you mean something else? No multiple hosts. Think Firewire or FibreChannel. We certainly cannot spin down a Firewire disk some other host is using just because we are done with it. > (I assume you mean something else, as the SCSI core certainly does know > when multiple SCSI devices are attached to a SCSI bus.) > > In any case, that's not how I would put it. The SCSI core and > high-level drivers will have to decide when they are not using SCSI > devices and the devices can be suspended. When all the devices the Err, why? After all, there's a central instance in userspace that decides that the whole system isn't used right now. I see no reason to not use this model for parts of the device tree. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
