From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrWtH-0008Aa-Ec for qemu-devel@nongnu.org; Thu, 11 Aug 2011 11:09:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrWtG-0006YY-Fy for qemu-devel@nongnu.org; Thu, 11 Aug 2011 11:09:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrWtG-0006YT-7c for qemu-devel@nongnu.org; Thu, 11 Aug 2011 11:09:46 -0400 Message-ID: <4E43F167.2030902@redhat.com> Date: Thu, 11 Aug 2011 17:12:39 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1312478089-806-1-git-send-email-pbonzini@redhat.com> <1312478089-806-6-git-send-email-pbonzini@redhat.com> <20110811075836.GB29542@stefanha-thinkpad.localdomain> <4E43C6CE.9070008@redhat.com> <4E43E619.601@redhat.com> <4E43E928.8060208@redhat.com> <4E43EFA9.4010501@redhat.com> In-Reply-To: <4E43EFA9.4010501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/10] dma-helpers: add dma_buf_read and dma_buf_write List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Stefan Hajnoczi , qemu-devel@nongnu.org Am 11.08.2011 17:05, schrieb Paolo Bonzini: > On 08/11/2011 04:37 PM, Kevin Wolf wrote: >>> Right, I would rather update BlockDriverCompletionFunc to pass the AIOCB >>> as a third parameter, and store the residual bytes in the DMAAIOCB (with >>> a getter that the completion function can use). >> >> Isn't the DMAAIOCB already passed as opaque to the callback? > > It is passed to the dma_bdrv_cb, but not to the caller-provided > callback. If the operation completes before dma_bdrv_{read,write} > returns, the AIOCB is not stored anywhere and the asynchronous callback > does not have access to it. Usually it does not have anything to do > with it, but in this case it could get the residual. > > Another possibility is always completing DMA in a bottom half. This > ensures that the callback can access the AIOCB, but it exposes an > implementation detail to the caller, so I don't like it. At least in the block layer, AIO callbacks may never be called before the submission function has returned. I think this makes the DMA helpers provide the same behaviour. But I'm not sure if the definition of the AIOCB struct isn't private to the block layer. Kevin