Re: [RFC] generic device DMA implementation
David Gibson (david@gibson.dropbear.id.au)
Sat, 7 Dec 2002 20:56:26 +1100
On Fri, Dec 06, 2002 at 10:26:57AM -0600, James Bottomley wrote:
> adam@yggdrasil.com said:
> > 	I like your term DMA_CONSISTENT better than DMA_CONFORMANCE_CONSISTANT
> > .  I think the word "conformance" in there does not reduce the time
> > that it takes to figure out what the symbol means.  I don't think any
> > other facility will want to use the terms DMA_{,IN}CONSISTENT, so I
> > prefer that we go with the more medium sized symbol. 
> 
> I'm not so keen on this.  The idea of this parameter is not to tell
> the allocation routine what type of memory you would like, but to
> tell it what type of memory the driver can cope with.  I think for
> the inconsistent case, DMA_INCONSISTENT looks like the driver is
> requiring inconsistent memory, and expecting to get it.  I'm open to
> changing the "CONFORMANCE" part, but I'd like to name these
> parameters something that doesn't imply they're requesting a type of
> memory.
Well, actually I was thinking of the flags as a bitmask, not an enum,
so I was assuming (flags==0) for not-neccessarily-consistent memory.
However, since having seen davem's comments, I agree with him that
separate entry points is probably a better idea for API sanity.
-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/