On Tue, May 24 2005, Jeff Garzik wrote: > Jens Axboe wrote: > >On Tue, May 24 2005, Jeff Garzik wrote: > > > >>The SCSI layer needs to issue the START STOP UNIT command in response to > >>a suspend event, and libata-scsi will (per SAT spec) translate that into > >>the ATA standby command. Merely following the relevant SCSI+SAT+ATA > >>standards gets us there. > > > > > >BTW, you also need to set host/device modes on resume. Where do you > >propose to do that currently, without the LLD hook? > > In the START STOP UNIT emulation. SSU is basically a high level "do PM > command". Ok, works for me. > As a tangent, I would like to try and convince you to stop thinking so > much about hooks, and start thinking about adding new commands at the > struct request level. Sending things down the request_queue is much > nicer because commands can be sent using the normal rq mechanisms. > Often, commands can be translated directly into ATA or SCSI commands in > the prep function. > > Two commands I have been thinking about, to add alongside READ, WRITE, > READA, READ_SYNC, etc. are: SYNC_CACHE and PM_EVENT. > > This would be quite useful for DM and md RAID, especially. It becomes > trivial to clone a SYNC_CACHE command, and send it to 5 underlying ATA > and SCSI devices in a RAID array. If the PM_EVENT or SYNC_CACHE command > needs special processing, one can easily add code for that without > needing any hooks -- just call your new code from the request_queue > function that handles READ/WRITE/READA/... > > This applies to the current thread (PM_EVENT), and also fits right into > your barrier work, too (SYNC_CACHE). I agree, it's a cleaner approach, with the rq being a container for generel messages as well not just SCSI commands. The one missing piece for that was the rq->end_io() callback so everything doesn't have to go down sync, but that is in now as well. I'll try and cook something up. -- Jens Axboe - : 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
