Date: Mon, 13 Oct 1997 16:13:07 +0930 From: Mike Smith <mike@smith.net.au> To: Kenneth Merry <ken@plutotech.com> Cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG, gibbs@plutotech.com Subject: IDE, ATAPI & CAM (was Re: HP 7100i) Message-ID: <199710130643.QAA00568@word.smith.net.au> In-Reply-To: Your message of "Sun, 12 Oct 1997 22:57:02 CST." <199710130457.WAA10342@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Mike Smith wrote... > Hmm. I really don't know enough about IDE to really say how it > should go. I guess the question to ask is, what exactly is the difference > between ATA and ATAPI? It's easier to address the opposite: what do ATA and ATAPI have in common? The answer is "the hardware interface". (Note that I should qualify this a little; by "atapi" I mean "devices using the SFF8020 'packet' interface). > In any case, the transport layer doesn't talk directly to the > hardware, it talks to the SIM (System Interface Module) layer. 'SIM' is > really just another way to say device driver. OK. In this case, the transport layer is basically just a switch that connects a request from a driver with the appropriate SIM (plus queueing, error retry, etc.). Correct? > If ATAPI is really almost like SCSI, and IDE disks have to talk > ATA, you could probably get away with something like the diagram below. > > > _______________ _______________ > | Application | | Application | > --------------- --------------- > | | > ---------------------------------------------------------------------- > | OS | > ---------------------------------------------------------------------- > | | | | | | > ---------- ---------- ---------- ----------- ----------- ----------- > | Disk | | Tape | | CDROM | | passthru| | Network | |IDE | > | Driver | | Driver | | Driver | | Driver | | Driver | |Disk Drvr| > ---------- ---------- ---------- ----------- ----------- ----------- > | | | | | | > ------------------|------------------------------------------ > | > | > ------------------- > | Transport (XPT) | > | Layer | > ------------------- > | > ------------------------------------------------------ > | | | | > -------------- -------------- ------------------- ------------------ > | SCSI (SPI) | | SCSI (FCP) | | Network | | SCSI-to-ATAPI | > | SIM | | FC SIM | | Interconnect SIM| | Translation ** | > -------------- -------------- ------------------- ------------------ > | | | | > | |<----------------| ------------ > | | | | IDE SIM | > -------------- -------------- -------------- ------------ > | Hardware | | Hardware | | Hardware | | > | Adapter(HA)| | Adapter(HA)| | Adapter(HA)| ------------- > -------------- -------------- -------------- |Hardware | > |Adapter(HA)| > -------------- > > (**): The SCSI-to-ATAPI translation would only be for transactions going > from a SCSI peripheral driver to an ATAPI peripheral. Transactions > coming from the IDE/ATA disk driver wouldn't need to be translated. That makes a lot more sense, yes. > I don't think the interface going out of or coming into the > transport layer is SCSI-specific. However, think there are some > assumptions that are SCSI specific, like the device probe stuff. The > transport layer assumes that it is going to get a SCSI inquiry data > structure back. I don't know what you get back from an IDE drive at probe > time. A lot of crap. 8) How much of the inquiry data structure is actually used? I presume it's not actually passed back down to the SIM for reuse, so a dummy could easily be constructed. > Do I want to write the code? Not really. Aside from time > constraints, I pulled the last two IDE drives out of one of my machines a > couple of months ago. So I don't even have the hardware to test it on. I appreciate this; I'd love to have the time and I do have the hardware, and if nothing else I'd like to come out of this with a better appreciation of what's really going on. If I can come up with code on top of that, I'd be even happier. 8) > After reading a little in the CAM spec, it seems like they think > the transport layer should understand both SCSI and ATA. I think the > current FreeBSD CAM transport layer could be made to understand ATA. Sounds respectable. Time to start reading the code in earnest. > So the task is definitely feasible, it'll just take someone with > time and the willingness to learn the pieces of the above puzzle that they > don't already know. :) *chuckle* Time, time time. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710130643.QAA00568>