Date: Tue, 4 Dec 2012 23:41:08 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Jeff Roberson <jeff@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: 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 Message-ID: <D41E579E-FBDA-4221-8BAC-77F27EE7B68F@scsiguy.com> In-Reply-To: <201212050451.qB54px6O065330@svn.freebsd.org> References: <201212050451.qB54px6O065330@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 4, 2012, at 9:51 PM, Jeff Roberson <jeff@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D41E579E-FBDA-4221-8BAC-77F27EE7B68F>