From: James Bottomley <James.Bottomley@steeleye.com>
Date: Fri, 06 Dec 2002 16:26:54 -0600
adam@yggdrasil.com said:
> This makes me lean infinitesmally more toward a parameter to
> dma_alloc rather than a separate dma_alloc_not_necessarily_consistent
> function, because if there ever are other dma_alloc variations that we
> want to support, it is more likely that there may be overlap between
> the users of those features and then the number of different function
> calls would have to grow exponentially (or we might then talk about
> changing the API again, which is not the end of the world, but is
> certainly more difficult than not having to do so).
I think I like this.
I don't.
If the concept isn't all that important, why bother?
See, if you have to allocate a whole new routine, you'll think
about whether it makes sense or not.
It's like adding a new system call, and the same arguments apply.
I don't want a 'flags' thing, because that tends to be the action
which opens the flood gates for putting random feature-of-the-day new
bits.
If you have to actually get a real API change made, it will get review
and won't "sneak on in". I also don't want architectures adding arch
specific flag bits that some drivers end up using, for example.
The suggested scheme allows that, and I can guarentee you that people
will do things like that.
You must take the time to get the semantics right and make sure they
really do handle the cases that are problematic. Random flag bits
passed to a "do everything" dma_alloc function don't encourage that at
all.
-
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:28 EST