Re: [PATCH] generic device DMA (dma_pool update)

[James Bottomley <James.Bottomley@steeleye.com>]

adam@yggdrasil.com said:
> 	Let me clarify or revise my request.  By "show me or invent an
> example" I mean describe a case where this would be used, as in
> specific hardware devices that Linux has trouble supporting right now,
> or specific programs that can't be run efficiently under Linux, etc.
> What device would need to do this kind of allocation?  Why haven't I
> seen requests for this from people working on real device drivers?
> Where is this going to make the kernel smaller, more reliable, faster,
> more maintainable, able to make a computer do something it could do
> before under Linux, etc.?

I'm not really the right person to be answering this.  For any transfer you 
set up (which encompasses all of the SCSI stuff bar target mode and AENs) you 
should have all the resources ready and waiting in the interrupt, and so never 
require an in_interrupt allocation.

However, for unsolicited transfer requests---the best example I can think of 
would be incoming network packets---it does make sense:  You allocate with 
GFP_ATOMIC, if the kernel can fulfil the request, fine; if not, you drop the 
packet on the floor.  Now, whether there's an unsolicited transfer that's 
going to require coherent memory, that I can't say.  It does seem to be 
possible, though.

James