[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: proposal for bus_dma(9) change
On Wed, 4 Mar 2009, Izumi Tsutsui wrote:
- Is there any benefit to change all bus_dma(9) implementation
instead of all drivers? I'm afraid the former is more complicated
because there are many hidden indirect calls via function pointers
in bus_dma structures/macro among machine/bus dependent implementation.
It shouldn't be hard to change bus_dmamap_create() implementation
to return a NULL dmamap pointer in error case.
How can you find all MD bus_dmamap_create() implementation in whole
MI/MD source tree?
I would suspect by a similar process of finding the calls in
the source tree :)
There are 698 references to bus_dmamap_create through the
tree, 29 are defines, 486 are of the form 'if (bus_dmamap_create'
or 'foo = bus_dmamap_create', and a fair chunk of the rest are
in printfs, comments, or other misc areas.
I'd estimate there would be fewer references to check in the
implementations than the callers.
Is it really easy for you than fixing all (but only problematic) drivers
It involves checking every caller, or every implementation. Once
done we will tend to have fewer new bus_dmamap_create
implementations than callers added...
Changing API is really pain than fixing bugs, IMO.
I can understand a reluctance to change bus_dma(9) if it made
it more complicated, or added extra overhead in a common path,
but this would appear to only change behaviour in the error case,
and does appear to be a genuine (small) enhancement to the API.
Making APIs easier and less error prone to use, particularly
in the uncommon case of error handling should be something
we should be encouraging.
If this API was being written from scratch now, and both options
were open - the easier way to dermine an error case or not, which
would we pick?
David/absolute -- www.NetBSD.org: No hype required --
Main Index |
Thread Index |