Date: Fri, 10 Oct 1997 23:19:26 -0600 (MDT) From: Kenneth Merry <ken@plutotech.com> To: hackers@freebsd.org Subject: Re: HP 7100i Message-ID: <199710110519.XAA22676@pluto.plutotech.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710110519.XAA22676>