On 08/24/05 07:03, Douglas Gilbert wrote: > 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. Ok. Just a general note to make my stance clear: I'm in favour of making lower layers as simple as possible, in order to allow greater _versatility_ at a _higher_ level. Of course none of this without following a well defined spec. > 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 Yes, I agree. > 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. Hmm. >>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. What I meant here by "Execute Task" is that when you call it, lldd->execute_task(), the task _immeditely_ goes out on the transport. That is, you're really touching the transport at that point. The concept of "passthrough" at this point is rather moot, _unless_ you are "passing through" something inside the task work to be done, which the transport wouldn't care. I like this shielding/separation, since it clearly defines what each layer needs to worry about. > 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. When I give you the "domain_device" you'll have that info in it, since of course obtaining it is transport specific, _unless_ you use the tools you mention above, which means you've already established a nexus to the device. > 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. Yes, I agree. Luben - : 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
