From owner-freebsd-hackers Fri Oct 10 22:19:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA01183 for hackers-outgoing; Fri, 10 Oct 1997 22:19:36 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA01175 for ; Fri, 10 Oct 1997 22:19:27 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id XAA22676 for hackers@freebsd.org; Fri, 10 Oct 1997 23:19:26 -0600 (MDT) From: Kenneth Merry Message-Id: <199710110519.XAA22676@pluto.plutotech.com> Subject: Re: HP 7100i To: hackers@freebsd.org Date: Fri, 10 Oct 1997 23:19:26 -0600 (MDT) X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry if anyone sees this twice, but I haven't seen it come through on hackers yet. So, I'm resending it, hopefully it'll get through this time. Ken =========================================================================== Mike Smith wrote... > > > > I think the way to go, if you want to add IDE support to the > > FreeBSD CAM code, is to write another transport layer to go alongside the > > current transport layer. Justin can elaborate on it a little more. (I've > > CCed him..) > > The situation is a little complicated, in that you have two > fundamentally different device types hung off the same interface. For > our purposes, these are ATA disks and ATAPI devices. > > The NetBSD approach creates an 'atapibus', off which ATAPI devices are > hung. These are registered with their SCSI layer, whilst IDE disks are > associated with their 'wd' driver. > > I'm not sure if you're suggesting that the IDE interface should be > parallelled with the SCSI interface, or whether you mean that the ATAPI > interface should be treated as though it were another SCSI adapter. > Perhaps the CAM docco will make things clearer. 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. 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: _______________ _______________ | Application | | Application | --------------- --------------- | | ------------------------------------------------------- | OS | ------------------------------------------------------- | | | | | ---------- ---------- ---------- ----------- ----------- | Disk | | Tape | | CDROM | | passthru| | Network | | Driver | | Driver | | Driver | | Driver | | Driver | ---------- ---------- ---------- ----------- ----------- | | | | | ------------------|------------------------------ | | ------------------- | Transport (XPT) | | Layer | ------------------- | --------------------------------- | | | -------------- -------------- ------------------- | SCSI (SPI) | | SCSI (FCP) | | Network | | SIM | | FC SIM | | Interconnect SIM| -------------- -------------- ------------------- | | | | |<----------------| | | | -------------- -------------- -------------- | Hardware | | Hardware | | Hardware | | Adapter(HA)| | Adapter(HA)| | Adapter(HA)| -------------- -------------- -------------- 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. 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. 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. The passthrough driver, though, is definitely generic enough to work with either SCSI or IDE drives. 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. Another way to add IDE support into CAM would be to put a translation layer, along the lines of what NetBSD has. (note: I haven't taken a good look at the NetBSD code, I may have misunderstood what it does...) Basically, it would sit between the current transport layer and the IDE hardware driver(s), and translate SCSIisms to IDEisms. You may still need IDE peripheral drivers, though. So which is a cleaner solution? I'm not sure, really. I guess the translation layer idea would allow more code sharing between IDE and SCSI, but how many kludges would it have to go through to do it? Depending on how it's done, you may still need IDE disk and CDROM drivers. Having separate transport layers that just share most of their code might work. But then you would still need separate IDE peripheral drivers. Anyway, I'm no expert on IDE or SCSI, so maybe some folks out there have other ideas that might work for this. I think it's definitely possible (NetBSD does it), the question is just what is the best way to do 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.) Ken -- Kenneth Merry ken@plutotech.com