From owner-freebsd-hackers Sun Oct 12 02:51:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA11710 for hackers-outgoing; Sun, 12 Oct 1997 02:51:40 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA11692 for ; Sun, 12 Oct 1997 02:51:07 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id TAA00803; Sun, 12 Oct 1997 19:15:26 +0930 (CST) Message-Id: <199710120945.TAA00803@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Kenneth Merry cc: hackers@FreeBSD.ORG, gibbs@plutotech.com Subject: Re: HP 7100i In-reply-to: Your message of "Fri, 10 Oct 1997 11:19:09 CST." <199710101719.LAA07863@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Oct 1997 19:15:25 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (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