On Tue, 2008-08-26 at 12:25 -0700, Gwendal Grignou wrote: > On Tue, Aug 26, 2008 at 10:45 AM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2008-08-26 at 10:25 -0700, Gwendal Grignou wrote: > >> The current patch to implement libata-sysfs floating in the mailing > >> list is read-only. > >> For write we must currently go through SCSI midlayer ioctls and use > >> sat. To send commands directly within libata[-sysfs] - for instance > >> writing SControl register of a SATA PM - I need to either implement a > >> queue mechanism over ata_exec_internal() or schedule eh and piggy back > >> on it. > > > > That's not how the other transport classes work, why does the libata one > > need to go through the mid-layer (well, except for the necessary command > > issue stuff, of course). The design of the transport classes was > > specifically to take all transport knowledge out of the mid layer and > > connect the requisite controls in sysfs directly to the transport > > actions. > I agree. I don't want to use the mid-layer either. I just mentioned > that if I want to send a raw taskfile to a ATA device today, the only > way I found is using ata_task_ioctl() which relies on the mid-layer to > schedule the request; the direct way - through ata_exec_internal() - > assumes only one outstanding command at a time. I need to implement > something else for the accessing ATA devices in libata-sysfs similar > to smp_execute_task() in libsas. Actually, no ... if you're sending a SATA task, then you're right, you need to use the mid-layer inputs. scsi_execute() is the way transport classes use this (see scsi_transport_spi ... it does exactly this for domain validation). ata_task_ioctl() does it exactly this way. You don't want something like smp_execute_task because that's an internal libsas API for doing out of band management tasks ... ATA has no concept of anything like this. Even our publicly exposed frame in/frame out interfaces for performing SMP tasks go via a special API stream in the transport class framework so they can be issued on all SAS hosts. Mechanistically, they're different from normal SCSI commands because they don't count against the queuing quota or have ordinary tags. If your commands come out again as standard ATA commands, I suspect they have to go through the standard ATA quota machinery. SAS is very different from SATA in that we have tons of addressable ports sitting off the devices, each addressable by predefined protocols, so what smp_execute_task is doing is addressing the SMP port ... this is completely out of band as far as the normal SSP/STP protocols see things. With port multipliers, you're more or less stuck with an in-band type of packet. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
