From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH][RFC] Refactor AIO to allow multiple AIO implementations Date: Thu, 11 Sep 2008 09:48:30 +0200 Message-ID: <48C8CD4E.1020705@redhat.com> References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Ryan Harper , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53805 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbYIKHu2 (ORCPT ); Thu, 11 Sep 2008 03:50:28 -0400 In-Reply-To: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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