Re: CAM

Andrew Valencia <vandys@cisco.com> writes:
> But the selection of SIM is a static answer for a particular instance
> of a PDRV, isn't it? So why couldn't have look it up once, via namer,
> open a port to the right SIM server process, and thus make it unnecessary
> to have a third process?

The data may not be static, and the XPT layer may be active during CAM
operation. In addition to routing CCB's, the XPT layer has the
following responsibilities:

        1) register/deregister SIM's. Note that a SIM could be registered
           and deregisterd many times. For example, SIM driver writers
           would do this during development.

        2) determine what devices are connected to each host adaptor.

        3) do asynchronous callbacks to the PDRV's. Asynchronous
           callbacks can occur, for example, when SIM's are
           registered/deregistered, when an unsolicited reslection or
           bus reset occurs, etc.

So, the XPT layer needs to be around in some form while CAM is operating.

Now, we've been presented w/ two alternatives as to where to put XPT:

Option 1:

Jonathon Tidswell <jont@hsa.com.au> writes:
> I hope that most of XPT and SIM can be joined as most systems will have more
> PDRV than SIM. [ 1 HBA, and several types of SCSI devices. ]

As long as there is just one SIM (ie, one host adaptor type), this
should work. If, however, there is more than one SIM, then you would
have to "chain" SIM's. That is, the XPT part of the first SIM process
would have to determine if a particular CCB is one it should handle. If
it isn't, the CCB would be passed to the next SIM (process) in the
chain, and so on. Note that CAM-for-DOS is specified to work this way.

Option 2:

As I wrote previously, there would be a separate XPT process. However,
the tables that the process maintains would be "exported" (possibly
through /namer) so that the XPT process would not be in the path
of SCSI I/O CCB's.

                                        Mike Larson
Received on Thu Sep 16 08:27:39 1993