I noticed a few issues related to multiple drivers accessing a single SIM
which Shishir's proposal on initialization and interrupt processing did not 
appear to address.  (I won't even mention the issue of pointer sizes. :-)

1.  Initialization
You suggest that the Caller (driver / Transport Module) calls the CAM 
Software (SIM?) to initialize it and build its data structures.  (Steps 2
and 3, Build Initialization Table and Initialize Device Block)  There is
a potential problem here if the SIM is in ROM and does not have its own
data area.  

If more than one driver can access the SIM (and isn't that the point
of CAM?) then each driver will attempt to initialize the SIM.  Each 
driver will create its own Init Table and CAM Device Block.  A SIM 
could indicate to a later caller that it has already been initialized 
and give the caller the address of its data structures, but a SIM
implemented in ROM might not have any way to store this information.


2.  Interrupts
If the device driver contains the interrupt service routine for the HBA,
and the CCB which completes was generated by a device driver other than
the first one in the interrupt sharing chain, control must be passed to
the next driver.  This is not a major problem if only one CCB can complete
for a single hardware interrupt, or even if no CCB completes, and only 
intermediate status is returned.  

However, in some environments, the SIM may be able to complete more 
than one CCB without generating additional hardware interrupts.  If 
the ISR is in the driver, this imposes on the driver the requirement
to not only process its on completed CCB, if any, but also to pass
control down the interrupt chain, even if the interrupt was applicable
to the first driver.


3.  Returned values
In some situations (Build Init Table) you suggest that the SIM return 
a value to the caller by replacing a value which the caller pushed 
onto the stack with the return value.  This will work in assembly
language, but not in some high-level languages.  Every C compiler that
I am familiar with throws away the parameters of a function call without
looking at whether they have been changed when the function returns.


Items 1 and 2 may be resolved by putting the initialization and 
interrupt handling functions into a single module which is logically
between the device drivers and the SIM.  I believe that this must
be the OSD module, because of the OS dependent nature of interrupt
service routines.  This module must have access to a static data area, 
to resolve the multiple initialization problem.  

The interrupt service routine may call the SIM to determine the cause 
of the interrupt and service the hardware.  It may also start or restart
one or more tasks which are queued within the SIM.  When the SIM returns
to the OSD module, zero, one or more CCBs may have been completed.  The 
OSD determines which CCBs, if any, completed and which drivers they 
belong to.  It then calls command completion routines in the appropriate
drivers.  There are several possible methods by which the driver 
previously informed the OSD module of the address to call.  Whichever
method is chosen, the OSD module maintains a way of associating each CCB
with its driver, and calls the appropriate routine when the CCB is complete.

This strategy was suggested in at least two earlier proposals put before
the committee, but was not included in the working document, for reasons
which are not entirely clear to me.  Although this may not be the only,
or even the best, method of solving these problems.  If anyone has a
better idea, I'd like to hear it.  In the mean time, I believe this 
is a workable solution to issues which are not adequately addressed 
in the currently accepted proposals.  


Chuck