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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:29 EST