svn commit: r243876 - in projects/physbio/sys: cam cam/ctl cam/scsi dev/aac dev/ahci dev/aic dev/arcmsr dev/ciss dev/hpt27xx dev/hptmv dev/hptrr dev/iir dev/isci dev/mly dev/mps dev/mpt kern

[Justin T. Gibbs]

On Dec 4, 2012, at 9:51 PM, Jeff Roberson <jeff at freebsd.org> wrote:

> Author: jeff
> Date: Wed Dec  5 04:51:59 2012
> New Revision: 243876
> URL: http://svnweb.freebsd.org/changeset/base/243876
> 
> Log:
>   - Arrange the cam ccb data flags into a 3 bit data type field so that it
>     can easily be parsed with a switch statement.  Define all physical
>     formats with the low bit set so drivers that don't support any physical
>     formats may easily reject them.

Most of the CAM ccb flags came from the original CAM specification,
so their existence in the header doesn't imply usage.  But, there
are some combinations that the old bit flags support that the new
definition does not.  For example, it was possible to independently
indicate the virtual/physical nature of a pointer to an S/G list
(controlled by CAM_DATA_PHYS) as well as the virtual/physical nature
of the data pointers within the list (controlled by CAM_SG_LIST_PHYS).

In general, I'd like to see this kind of knowledge extracted from
CAM in a way that allows data of different formats to be transferred
seemlessly between userland/kernel and kernel subsystems.  It should
be possible for the constructor of a request to specify it in a
manner convenient to it (e.g. user addresses) and have the processor
convert it into the format necessary to execute the request.
bus_dmamap_load (or even bus_vmap_load() if kernel access is required?)
already has callback semantics so even potentially blocking operations
(like the pinning of user space pages) could be deferred until load time.

Just within CAM we have lots of ugly code to deal with address and
data format mapping: CAM ccbs that originate from userland go through
a complicated mapping process (see cam_periph_mapmem), CTL jumps
through different hoops depending on whether its backing store is
a file (needs a uio) or a block device (multiple bios), and the
driver bits your earlier commit cleans up.

I know the immediate goal is to get unmapped I/O working, but it would
be nice to at least define a path toward fixing the rest of this
problem.

--
Justin