From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LmpAl-0001aV-9Y for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:59:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LmpAg-0001VR-EU for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:59:02 -0400 Received: from [199.232.76.173] (port=36592 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LmpAg-0001VE-4u for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:58:58 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35565) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LmpAf-000770-JM for qemu-devel@nongnu.org; Thu, 26 Mar 2009 08:58:57 -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 n2QCwuRQ024808 for ; Thu, 26 Mar 2009 08:58:56 -0400 Message-ID: <49CB7C0F.7010507@redhat.com> Date: Thu, 26 Mar 2009 14:58:55 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] honor IDE_DMA_BUF_SECTORS References: <49CA4C3D.1070705@redhat.com> <49CA59AE.8060605@eu.citrix.com> <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> <49CB70AC.3060900@redhat.com> <20090326124719.GL5642@const.bordeaux.inria.fr> In-Reply-To: <20090326124719.GL5642@const.bordeaux.inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: > Avi Kivity, le Thu 26 Mar 2009 14:10:20 +0200, a =E9crit : > =20 >> I realize your use case will probably not trigger this, but it does=20 >> indicate you're limiting at the wrong layer. It places the burden on=20 >> all callers of block format drivers instead of centralizing it. >> =20 > > Then it should be centralized in the block layer instead of placing the > burden on all block format drivers ;) > =20 If other drivers need to do that, certainly. However I expect that most=20 drivers are interested in increasing dma sizes rather than decreasing the= m. > One thing for instance that still have been overlooked although patches > have been sent is block-raw-posix' read/write_pread_aligned() that > consider partial read/writes as an error. That's a bug. > =20 Right. Unrelated topic though? --=20 error compiling committee.c: too many arguments to function