CAM-3 March Working Group Minutes

Mark Evenson mevenson at
Thu Mar 30 19:07:56 PST 1995

Lansing et al,

> CAM Folks,
> These notes are in response to Mark Evenson's comments on the CAM-3
> March 1995 Working Group minutes.  Where I did not comment on Mark's
> comments, I either agree or don't know enough to care.
> ...
> >> CAM_U32  -    An unsigned a 32 bit quantity.
> >> CAM_S32   -   An signed a 32 bit quantity.
> >> 
> >> Pointer sizes within CAM-3 structures shall be a power of 32 bits 
> >> and shall be the size that the O.S. defines for its pointer size 
> >> rounded up to a power of 32 bits.  The following is an example of 
> >> pointer size rules:
> >Should change "power" to "multiple" in previous paragraph.
> Actually, "power of 32 bits" should be "power of 2 bits", both times,
> and text should be added to specify that the minimum is 32 bits,
> to make the text consistent with the example that follows.
> This changed as the result of a long and incompletely resolved debate.
> The problem was, if an o.s. defined a pointer to be (say) 65 bits,
> we did not particularly want to round up to 96 bits because 64-bit
> processors would prefer 128 bits.  A couple of attendees (me, for one)
> were puzzled by why 32 was treated preferentially to either 16 or 64,
> and the power-of-2 choice made us happy (without solving the puzzle :).

My 2 cents: 32 bits is the largest integer size currently supported by
many actual compilers, so that would be the reason for it being the 
largest field size (as Bill alluded to somewhere I believe).  As far
as the pointer size being a minimum of 32 bits, that's probably
because interesting systems currently are pretty much 32-bit or
larger machine architectures.

> Possibly the minutes could say more about the rationale for changing from
> a multiple of 32 bits to a power-of-2-bits-with-minimum-of-32 approach.

Yeah, this is probably the right approach, so we need to change from 
"power of 32 bits" to something like "power of 2 number of bits with a
32-bit minimum" (other than being a little wordy it's ok :-]).

> >> OS Pointer Size
> >> CAM-3 Structure Storage Size
> >> 
> >> 1 to 32 bits
> >> 32 bits
> >> 
> >> 33 to 64 bits
> >> 64 bits
> >> 
> >> 65 to 128 bits
> >> 128 bits
> ...
> There is still some favortism toward 32 bits in that the largest
> CAM-defined field size is 32 bits and the minimum pointer size is
> 32 bits.  If the largest field size were larger than the minimum
> pointer size, the following requirement would have to be improved:
> >> All structures and structures within structures shall be aligned to 
> >> the naturally aligned pointer boundary.
> This might also be worth mentioning in the minutes.  And possibly
> these design considerations could be mentioned in a NOTE in CAM-3.


> >> ...
> >> 
> >> CCB * xpt_ccb_alloc( )
> >> 
> ...
> >> modified by the peripheral driver.  The allocated CCB can only be 
> >> used (i.e., sent to the XPT), once.  Once the CCB has completed it 
> >> shall be returned using the xpt_ccb_free service.
> >Why can the CCB only be used once?  I noticed this in CAM-1 as well.
> We discussed this.  I don't remember the conclusion.  It would be
> nice if the minutes could state why.  (Perhaps a NOTE in the standard
> would help, too.)
> ...
> >> CAM_U32 xpt_action(CCB *) 
> >> 
> >> All CAM CCB requests to the XPT or a SIM/HBA are placed 
> >> through this service call.  The CAM Status information for 
> >> callback on completion CCBs shall be obtained at the callback 
> >> point via the CAM status fields. The CAM Status information for 
> >> non callback on completion - non immediate CCBs shall be 
> >> obtained by polling the CAM status field for a non Request in 
> >> Progress status.
> >This kind of mechanism assumes single domain I/O subsystems in which
> >the PD, XPT and SIM are all in the same domain.  CAM-3 should in a
> >portable way anticipate more than this as a future looking standard.
> Though I fully agree with Mark's second sentence, I don't see where
> the assumption of a single domain comes in.

In the CAM model the PD is allowed to poll the CCB (eg. read the CAM
status) after it has sent it to the XPT/SIM.  This doesn't work in
general in different address space domains, let alone if the PD, XPT,
and SIM are in different endian domains or on separate machines.

> >>                   The CAM Status information for immediate 
> >> CCBs shall be obtain on return from the service call by examining 
> >> the CAM Status field.
> >Same as previous comment, plus is essentially precluded with implicit
> >synchronization.
> I'm still don't understand.

With implicit synchronization you can't have immediate CCBs because
when the xpt_action call returns (assuming you've added implicit 
synchronization semantics onto it) it won't necessarily have been
seen by the SIM and acted on yet (because it's queued in a 
sychronization queue).

> ...
> >Unfortunately, this least common denominator approach is probably
> >necessary to maximize portability.  But CAM-3 would have a lot more to 
> >do to truly maximize portability across multiple OS's and platforms
> >(eg. abstractions/interfaces for DMA, PIO, endianness, interrupts, 
> >MP synchronization, etc.), so one could argue as to the importance of
> >maximizing it in this one dimension unless the others are addressed also.  
> Does this suggest additional topics for CAM-3 to explore?

Yes.  There's an effort called CDDE that has done a fair amount of work
in these areas, that might be worth syncing up with.

> -- Lansing Sloan


 Mark Evenson		Hewlett-Packard       Cupertino Open Systems Lab
 mevenson at	Voice: 408/447-5601   Fax: 408/447-4380
 19447 Pruneridge Ave	MS 47LA		      Cupertino, CA 95014

More information about the T10 mailing list