From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ln9l0-00016L-0C for qemu-devel@nongnu.org; Fri, 27 Mar 2009 06:57:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ln9kv-00014o-6R for qemu-devel@nongnu.org; Fri, 27 Mar 2009 06:57:49 -0400 Received: from [199.232.76.173] (port=53330 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ln9kv-00014h-0b for qemu-devel@nongnu.org; Fri, 27 Mar 2009 06:57:45 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52557) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ln9ku-0000lP-FV for qemu-devel@nongnu.org; Fri, 27 Mar 2009 06:57:44 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2RAvhvD011863 for ; Fri, 27 Mar 2009 06:57:43 -0400 Message-ID: <49CCB14C.1080607@redhat.com> Date: Fri, 27 Mar 2009 13:58:20 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS References: <49CA5F9F.5040203@redhat.com> <49CA60BA.5060704@eu.citrix.com> <49CA6E4A.4080408@eu.citrix.com> <49CB5793.4030006@redhat.com> <49CB599D.6000701@eu.citrix.com> <49CB5FA0.10101@redhat.com> <49CB6AF7.3080604@eu.citrix.com> <20090326224229.GA7311@lst.de> <20090326232230.GF5458@const.famille.thibault.fr> <49CCA449.4010504@redhat.com> <20090327103628.GF5408@const.bordeaux.inria.fr> In-Reply-To: <20090327103628.GF5408@const.bordeaux.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Samuel Thibault wrote: >> But posix read/write does not fit how DMA works. A request should >> either complete fully, or fail, leaving the destination (disk or >> memory) in an undefined state. >> > > Sure. Again, please read what _I_ wrote: I'm not proposing to expose > that into DMA, just make it genericly handled in the block layer. Okay. I oppose making short reads part of the API. Callers should expect the return code to be either zero, or a failure indication. If you want generic block layer support, it could come in the form of helpers, that is a block format driver could call bdrv_continue_partial_request(lots, of, parameters) to have the helper advance the iovec and reissue the partially completed request. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.