Re: [RFT][PATCH] generic device DMA implementation

David Brownell
2002-12-28T02:16:58Z

Hi,

>>- DMA mapping calls still return no errors; so BUG() out instead?
>
>
> That's actually an open question. The line of least resistance (which is what
> I followed) is to do what the pci_ API does (i.e. BUG()).

That might have been appropriate for PCI-mostly APIs, since those tend to
be resource-rich. Maybe. (It always seemed like an API bug to me.)

I can't buy that logic in the "generic" case though. Heck, haven't all
the address space allocation calls in Linux always exposed ENOMEM type
faults ... except PCI? This one is _really_ easy to fix now. Resources
are never infinite.

> It's not clear to me that adding error returns rather than BUGging would buy
> us anything (because now all the drivers have to know about the errors and
> process them).

For me, designing any "generic" API to handle common cases (like allocation
failures) reasonably (no BUGging!) is a fundamental design requirement.

Robust drivers are aware of things like allocation faults, and handle them.
If they do so poorly, that can be fixed like any other driver bug.

>> Consider systems where DMA-able memory is limited (like SA-1111,
>> to 1 MByte); clearly it should be possible for these calls to
>> fail, when they can't allocate a bounce buffer. Or (see below)
>> when an invalid argument is provided to a dma mapping call.
>
>
> That's pretty much an edge case. I'm not opposed to putting edge cases in the
> api (I did it for dma_alloc_noncoherent() to help parisc), but I don't think
> the main line should be affected unless there's a good case for it.

Absolutely *any* system can have situations where the relevant address space
(or memory) was all in use, or wasn't available to a non-blocking request
without blocking, etc. Happens more often on some systems than others; I
just chose SA-1111 since your approach would seem to make that unusable.

If that isn't a "good case", why not? And what could ever be a "good case"?

> Perhaps there is a compromise where the driver flags in the struct
> device_driver that it wants error returns otherwise it takes the default
> behaviour (i.e. no error return checking and BUG if there's a problem).

IMO that's the worst of all possible worlds. The error paths would get
even less testing than they do today. If there's a fault path defined,
use it in all cases: don't just BUG() in some modes, and some drivers.

- Dave