Re: libata bridge limits

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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@hansenpartnership.com> 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