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. > > The (semi)direct analogue of writing SControl of a SATA PM is writing a > phy control parameter of a SAS expander ... that's all accomplished in > libsas/scsi_transport_sata without ever going via the mid-layer. Agree. Gwendal. > >> Once implemented, we could definitely use it in conjunction with udev >> to tune ATA devices. > > 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
