Luben Tuikov wrote: > On 08/22/05 01:12, Douglas Gilbert wrote: > >>I was surprised how much code needed changing. >>With MODE SELECT's issues with libata addressed >>various other SAT "extras" should be much easier >>to implement. That should make libata more attractive >>as a SAT layer for SAS LLDDs (that don't do it already >>in firmware). > > > Doug, how about never needing a SAT layer for SAS LLDDs > for ATA/ATAPI devices. Well that might make things easier for the SAS LLDD driver writer but may not change things a lot upstream. The primary target for SAT is a layer within SAS enclosures/expanders sitting between a SATA transport with one or more SATA disks at the other end and SSP. Evidently SSP has advantages over STP in this role. Further, SATL isolating SATA devices from a multi-initiator SAS fabric, can manage SCSI tags from multiple initiators and map them onto the SATA disk's NCQ tags. Basically SATL adds value at that level. [It is also a useful document to improve all those horrible USB/1394 mass storage SCSI translation layers out there (but I'm not holding my breath)]. So from the point of view of a SAS LLDD, SATA disks (LUs) will appear both via STP and SSP. > Would you object if I "give" you a "domain device" to which > you can send FISes (+ the packet if ATAPI) through > a SAM-4 intefrace: Execute Task + TMFs? Well that is what CSMI (SDI) does and I think we will be implementing its functionality one way or another ;-). I just checked SDI and it allows the STP_PASSTHROUGH to be replaced by a SAT (like) emulation. That is when the SDI_STP_PASSTHROUGH ioctl can return SDI_SCSI_EMULATION which tells the user to go away and use the SAT like interface :-). That is why I said that it may not change things a lot upstream. As for ATAPI, 99% of the time it is conveying MMC set. With BD and HD-DVD coming down the line, app writers in that space probably won't want to worry about transport issues any more than they absolutely need to. SAT defines a "ATA information" VPD page (0x89) which conveys back the response to IDENTIFY DEVICE (for non-packet devices) or IDENTIFY PACKET DEVICE. SAT also defines 12 byte and 16 bytes ATA PASSTHROUGH SCSI commands which would be handy for smartmontools. Looking at SAT draft, I would suggest that it is an immature state, being work in progress (most recent teleconference: yesterday). And libata is trailing SAT by a good bit. And libata needs to slide over something like you are suggesting to be useful in the SAS context. I intend to take up the issue of SMP in another post. Doug Gilbert - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
