Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Oct 1997 19:15:25 +0930
From:      Mike Smith <mike@smith.net.au>
To:        Kenneth Merry <ken@plutotech.com>
Cc:        hackers@FreeBSD.ORG, gibbs@plutotech.com
Subject:   Re: HP 7100i 
Message-ID:  <199710120945.TAA00803@word.smith.net.au>
In-Reply-To: Your message of "Fri, 10 Oct 1997 11:19:09 CST." <199710101719.LAA07863@pluto.plutotech.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

(I've removed most of the cc's here, as I'm fairly sure the parties are 
-hackers readers.)

> 
> 	Actually, I'm suggesting that the IDE interface be parallelized
> with the SCSI interface.  (And it isn't actually my idea -- Justin first
> suggested it.)  It should be possible to create an IDE transport layer that
> uses a lot of the same code as the SCSI transport layer.  

Fair enough.  That's a fairly massive undertaking though; not something 
I'm about to undertake on my minimal free time.  8)

> 	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.

> 	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?

> 	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?

> 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*

At any rate, the only problem with this arises with the ATA transport 
layer, which would have to translate accordingly.

> 	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.

> it?  When he gets some time, perhaps Justin can comment on this.  (He wrote
> most all of the transport layer after all...so he has a better idea of the
> issues that would come up in trying to get IDE devices to work with it.)

I'd really like to hear about this, if you have the time Justin.  

mike





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710120945.TAA00803>