TO: All

FROM: Greg Slaughter

SUBJECT: DMA resources

The functional I/F for resource allocation that I presented
at the last meeting in Austin allows device drivers (eg. tape, disk,
etc.) to I/F with the next lower layer (whatever it is called?) in
an OS-independent manor.  IbqDpt would be desirable if we could get
something like what I presented (so it would work for OS/2 and DOS)
into the working documents.  Could those people who work with DOS
and OS/2 look intoi this?
Whether or not this can be done, there is one change to the working
document which is feasible now, and in fact necessary for
allowing CAM to be applicable generally to a wide range of platforms:
the working document should be updated so that the CCB has all DMA
resource objects (address info of data buffer, MMU info, direction
of xfer, page table info, DMA resource info, length of xfer,
etc.) stored in a private part of the CCB, and nowhere else
in the CCB.  After the meeting Clinton Ballard and I
discussed the resaons for such a change to the working document,
and we both agreed that such a change is necessary.  In discussing this,
we considered a few specific examples.  Without discussion here of the 
specific examples, essentially the reason is that the set of objects
which constitute DMA resources depends upon the platform.  Thus
this set of DMA resource objects can vary considerably, depending upon
such things as the OS, system bus, MMU, and virtual memory system.
These objects should only be specified on a per-platform basis.
Thus, for the IBM PC-compatible, it is possible to specify in
particular what the DMA resource objects are and which fields where
they are stored in the private part of the CCB.  I would like to see
both of the working documents updated with this simple change before
the next meeting.
Greg Slaughter, Sun Microsystems