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/