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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
