From owner-freebsd-hackers Sun Oct 12 23:49:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22998 for hackers-outgoing; Sun, 12 Oct 1997 23:49:14 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22992 for ; Sun, 12 Oct 1997 23:49:08 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA00568; Mon, 13 Oct 1997 16:13:08 +0930 (CST) Message-Id: <199710130643.QAA00568@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Kenneth Merry cc: mike@smith.net.au (Mike Smith), hackers@FreeBSD.ORG, gibbs@plutotech.com Subject: IDE, ATAPI & CAM (was Re: HP 7100i) In-reply-to: Your message of "Sun, 12 Oct 1997 22:57:02 CST." <199710130457.WAA10342@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Oct 1997 16:13:07 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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