From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N2L5p-0003M2-JE
	for qemu-devel@nongnu.org; Mon, 26 Oct 2009 04:38:21 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N2L5k-0003Kn-Jh
	for qemu-devel@nongnu.org; Mon, 26 Oct 2009 04:38:20 -0400
Received: from [199.232.76.173] (port=48253 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N2L5j-0003KW-6D
	for qemu-devel@nongnu.org; Mon, 26 Oct 2009 04:38:15 -0400
Received: from mx1.redhat.com ([209.132.183.28]:49471)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1N2L5i-0005tB-Ny
	for qemu-devel@nongnu.org; Mon, 26 Oct 2009 04:38:15 -0400
Message-ID: <4AE55FA7.5070209@redhat.com>
Date: Mon, 26 Oct 2009 09:36:55 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1256031192-8292-1-git-send-email-kwolf@redhat.com>
	<4ADD8D27.7090705@redhat.com> <20091022083156.GC27577@lst.de>
	<4AE02073.6030403@redhat.com> <20091025071907.GA17121@lst.de>
In-Reply-To: <20091025071907.GA17121@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] raw/linux-aio: Also initialize POSIX AIO
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Am 25.10.2009 08:19, schrieb Christoph Hellwig:
> On Thu, Oct 22, 2009 at 11:05:55AM +0200, Kevin Wolf wrote:
>> Yes, it might look like overkill to introduce a abstraction for exactly
>> two backends. I felt the same way. But then, the current implementation
>> just feels totally wrong. It absolutely intransparent when we fall back
>> to paio, and before debugging the bdrv_read/write emulation I didn't
>> even know that we're doing it. And, like I said, why should a block
>> format driver know what AIO method works which way?
> 
> Because the aio method is part of the block driver.  Despite our
> code organization linux-aio.c and compat-posix-aio.c aren't generic
> abstractions but sub-modules of raw-posix.

Well, my question was not if they are sub-modules of raw-posix - they
clearly are - but rather if they should be.

But ok, I'll just submit a patch drop the context parameter in paio_* then.

Kevin