CAM-3 March Working Group Minutes
mevenson at hposl21.cup.hp.com
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
> 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
> >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 cup.hp.com Voice: 408/447-5601 Fax: 408/447-4380
19447 Pruneridge Ave MS 47LA Cupertino, CA 95014
More information about the T10