Date: Sun, 12 Oct 1997 22:57:02 -0600 (MDT) From: Kenneth Merry <ken@plutotech.com> To: mike@smith.net.au (Mike Smith) Cc: ken@plutotech.com, hackers@FreeBSD.ORG, gibbs@plutotech.com Subject: Re: HP 7100i Message-ID: <199710130457.WAA10342@pluto.plutotech.com> In-Reply-To: <199710120945.TAA00803@word.smith.net.au> from Mike Smith at "Oct 12, 97 07:15:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote...
> > The CAM-3 spec has a nice diagram of the various parts of CAM in
> > section 5.1, page 17. Basically, it goes like this:
>
> [diagram munged]
>
> > ------------------+---------------------------+--
> > | |
> > | |
> > ------------------- ---------------
> > | Transport (XPT) | | Transport |
> > | Layer (SCSI) | | Layer (ATA) |
> > ------------------- ---------------
> > | |
> > ,---------------+---------------. |
> > | | | |
> > -------------- -------------- --------------- |
> > | SCSI (SPI) | | SCSI (FCP) | | ATAPI SIM | |
> > | SIM | | FC SIM | | | |
> > -------------- -------------- --------------- |
> > | | | |
> > | | |----------'
> > | | |
> > -------------- -------------- -------------------
> > | Hardware | | Hardware | | Hardware (IDE) |
> > | Adapter(HA)| | Adapter(HA)| | Adapter(HA) |
> > -------------- -------------- -------------------
> Is this more or less what you had in mind? ie. SCSI transport over
> ATAPI to the peripheral, sharing an adapter with the ATA transport
> layer? All you'll see on the ATA transport are disks, while ATAPI is
> likely to encompass cdroms, tapes, disks, you name it.
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?
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.
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.
The
_______________ _______________
| 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.
Disclaimer: I know very little about IDE, ATA, ATAPI, etc...
> > So, I guess one question here is how SCSI-specific is the current
> > transport layer? IMO, for the most part it is generic enough to handle
> > IDE and SCSI commands, but there are some parts that are tuned to SCSI
> > devices.
> Hmm. Do you want to do this? Is the interface out the bottom of the
> transport layer in the current case SCSI-specific?
[ I'm treading on thin ice here, Justin knows more of what's going on in
this department ]
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.
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.
> > There are a couple of different ways to go about adding IDE support
> > into CAM. One way would be to separate the transport routines that are
> > SCSI-specific from the main body of the transport code. Then you would
> > write equivalent IDE routines, and have two separate transport layers. The
> > IDE layer would talk to the IDE harware driver(s), and the SCSI layer would
> > talk to the SCSI hardware drivers.
>
> That's more or less what I've described above, I believe; correct?
Yes, almost. The ATA/IDE transport layer would talk to the
hardware driver instead of the hardware.
> > One problem that comes up with this
> > method is that some of the peripheral drivers, notably the DA (Direct
> > Access) and CDROM drivers are fairly SCSI-specific. There are certainly
> > elements of the drivers that would apply to IDE drives, but they are also
> > full of SCSI commands.
> This seems to defy the whole idea of CAM though, doesn't it? Aren't
> the periperhal drivers meant to be working to some abstract model?
> *ponder*
Well, maybe, maybe not. At some point, you have to translate the
general notion of what a drive is to do back into something the device can
understand. The CAM spec does seem to assume that there will be a distinct
ATA disk driver.
> At any rate, the only problem with this arises with the ATA transport
> layer, which would have to translate accordingly.
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.
> > You'd probably end up having separate IDE direct-access,
> > sequential-access, and possibly CDROM drivers. They would probably
> > somewhat similar to their SCSI counterparts. The main benefit would be
> > code-sharing between the transport layers.
> Ah, I'm with you. All you would need would be a separate ATA-specific
> direct-access driver; just about everything else is packet-mode ATAPI,
> which is basically just SCSI.
Hmm. In that case, my diagram above might work, or it might not.
It may be possible to just put code in the current transport layer so that
it understands ATA devices.
Getting IDE devices working with CAM will most likely take the
following on the part of the coder:
1) An understanding of what parts of the current transport layer are
SCSI-specific, and therefore need to be changed to accomodate either
IDE or SCSI devices.
2) A good idea of the similarities between ATAPI and SCSI. This is
necessary to know how to translate between ATAPI and SCSI. A look at
the NetBSD code might be a good idea for this.
3) Enough knowledge of IDE and CAM to write the IDE/ATA disk driver and
the IDE hardware driver. A lot of this code can probably be snarfed
from code that's already written.
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. :)
Ken
--
Kenneth Merry
ken@plutotech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710130457.WAA10342>