From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kdgw6-0004Q8-6P
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:54 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kdgw4-0004Ot-Td
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:53 -0400
Received: from [199.232.76.173] (port=38796 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kdgw4-0004OW-DQ
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:52 -0400
Received: from mx2.redhat.com ([66.187.237.31]:34891)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Kdgw3-0006GQ-Se
	for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:52 -0400
Message-ID: <48C8CD4E.1020705@redhat.com>
Date: Thu, 11 Sep 2008 09:48:30 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com>
In-Reply-To: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH][RFC] Refactor AIO to allow multiple AIO
	implementations
Reply-To: qemu-devel@nongnu.org
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: Anthony Liguori <aliguori@us.ibm.com>
Cc: Ryan Harper <ryanh@us.ibm.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

Anthony Liguori wrote:
> This patch refactors the AIO layer to allow multiple AIO implementations.  It's
> only possible because of the recent signalfd() patch.  
> 
> Right now, the AIO infrastructure is pretty specific to the block raw backend.
> For other block devices to implement AIO, the qemu_aio_wait function must support
> registration.  This patch introduces a new function, qmeu_aio_set_fd_handler, which
> can be used to register a file descriptor to be called back.  qemu_aio_wait() now
> polls a set of file descriptors registered with this function until one becomes
> readable or writable.

Hmm, what is the long-term plan for this?  Separating out the completion
notification is a nice first step.  Most of the aio infrastructure is
still in the block raw backend though.  IMHO it doesn't belong there.

The aio implementation(s) should be a separate entity usable by all
block backends to invoke aio requests, without having to care about how
this is actually implemented (threads, linux aio, posix aio, whatever).

cheers,
  Gerd