From: jag@decvax.DEC.COM (John A. Gallant UEG)
Subject: Re: SCSI/CAM Request For Information
Reply-To: jag@zk3.dec.com
Organization: OSF Engineering, Digital Equipment Corp.
Date: Tue, 29 Dec 1992 15:46:03 GMT

In article <1992Dec16.191430.1667@pt.com>, rcw@pt.com (Ray Ward) writes:
>I am working on a SCSI driver for the NCR53C720 product.  It is a dual
>channel board.  I have read the SCSI/CAM specification and think that
>would be the way to implement a driver.  I am doing the driver on a
>System VR3 platform.  I have the following questions regarding the init
>portion of the modules.
>
>1)  The spec talks about a configuration_driver().  What is the format of
>    this and how is it invoked (directly from the kernel or from the XPT)?

    During this part of the CAM committee work we could not cast in stone
the proper initialization sequence for all of the various OSD sections or
even within the SVR* and B*D camps.  We agreed that there needed to be 
a single "driver" phesudo or other wise, that needed to be responsible for
the configuration/initialization of all the SIMs and XPT modules.  This
module was called the configuration module and it was the responsibilty
of the system vendor to provide this with their CAM implementation.

    There was no way, that we could guarantee, that would ensure that 
the configuration driver would be called before any of the SIMs or 
any of the peripheral device drivers.  There was the requirement that
the peripheral device drivers call the xpt_init() routine all the time.
The SIM side of things is left to the system vendor. 

    The interaction between the configuration driver and XPT should be
straight forward.  If the configuration driver is initialized then it
would initialize the XPT, and if the xpt_init() routine is called and
the XPT is not initialized yet it could call the configuration driver.

>    This module sets up the cam_edt[] table.  How is the relationship
>    between the physical device parameters (SCSI ID, device type, etc)
>    and the logical device name made (is the information contained in
>    the cam_edt[] and if so, who sets it up?)?  How does the
>    configuration_driver() know about the existence of any SIM's?

    The EDT structure is accessed using the Bus/Target/LUN information
only.  It should only contain any INQUIRY information, and possably the
Async callback information.  Any mapping between the /dev/* and SCSI
Bus/Target/LUN is totally up to the peripheral device driver and not 
the SIM.  The SIM only deals with the Bus/Target/LUN information.

    The configuration driver has two ways, there are others, that it would
know about SIMs.  It can use the Path Inquiry CCB to determin how many
SIMs are in the XPTs table and then call each possible one to get it 
setup.  This would require a static table of SIM_ENTRYs that the XPT
knows about.  The other way, depending on how the OS does thing, the 
SIMs could have their own "configuration point" that also inturn calls
the configuration driver to complete the initialization.

>2)  How does the peripheral driver or the XPT access the cam_edt[] or the
>    cam_conftbl[] (are they both global)?

    They are *NOT* global to the peripheral device drivers.  The GET/SET
device type CCBs are to be used by the peripheral device drivers.  The 
format and content of these structures are described but the system vendor
that provides the XPT and configuration driver has the option to do
what ever is necessary for their implementation.  For example our
configuration driver handles the GET/SET CCBs and the XPT deals with the
async callback handling.  For both of these modules the cam_edt[] is 
common but that is between "consenting modules".  The cam_conftbl[] 
is also not global to non XPT/configuration driver modules.

>3)  When performing the auto-scan, is the device existence tested for at
>    the SIM level or does the XPT set up a Test Unit Ready CCB and issue
>    it to the SIM?  Is this information passed to the configuration_driver()
>    or is the cam_edt[] writable by both the XPT and SIM?

    First of all the auto-scan should only use the INQUIRY CDB, any other
SCSI command will affect any pending Unit Attention conditions that the
devices may have.  Loosing the pending Unit Attention can have a
disasterous effect on tape devices and their drivers.  According to the
CAM spec we wanted to have a single bus scan done on the system.  The 
logical place was within the XPT/configuration driver modules.  This
way the SIMs would not have to worry about having to create CCBs and also
inturn deal with understanding the data.

-- 
John A. Gallant                                jag@zk3.dec.com
Software Engineer - OSF Engineering Group
Digital Equipment Corp. (603) 881-2472

        In the common people there is no wisdom, no penetration, no
        power of judgment.
    Marcus Cicero
Organization: Sophomore, Civil Engineering, Carnegie Mellon, Pittsburgh, PA