On Thu, Nov 08, 2007 at 03:49:17PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >On Thu, Nov 08, 2007 at 03:19:52PM -0500, Mark Lord wrote:
> ..
> >>MMmm.. I wonder what the most common use case is for target mode?
> >>
> >>Everybody I've dealt with thus far uses it as a high-speed local comms
> >>interface,
> >>which would suggest that it might be done as a network interface
> >>(ethernet emulation).
> >>
> >>But that would confusingly go across driver subsystems,
> >>despite that this is how it actually is used.
> >
> >The low-level driver itself will just be a dumb DMA send/receive engine,
> >with submit/completion APIs highly similar to the existing ones. Then
> >you can easily provide a network interface interface (not a typo) on top
> >of that.
> ..
>
> The obvious BIG difference is that in host mode, *we* initiate
> communcations,
> whereas in target mode, it has to just sit there waiting for a host to say
> something.
>
> That's a pretty big change from how libata operates today,
> in just about every respect.
Not at all -- both initiator and target modes have the exact same tasks:
1) send stuff to hardware, 2) receive hardware responses.
On modern SAS/SATA hardware, you have both command and response queues.
On modern SATA hardware, you have command queue and a received FIS list,
which provides essentially the same services.
Thus SATA target mode will simply need a "here is data I just received
from the wire" hook, and the rest of the infrastructure already exists.
Target mode will re-use ->qc_issue, and need a new ata_receive_fis()
function for asynchronously received FIS's (H2D FIS, etc.)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
