lkml.org 
[lkml]   [2002]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFT][PATCH] generic device DMA implementation
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

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.109 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site