From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0tdX-0005xe-BA for qemu-devel@nongnu.org; Thu, 22 Oct 2009 05:07:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0tdS-0005wc-8d for qemu-devel@nongnu.org; Thu, 22 Oct 2009 05:07:10 -0400 Received: from [199.232.76.173] (port=41481 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0tdS-0005wZ-1O for qemu-devel@nongnu.org; Thu, 22 Oct 2009 05:07:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58749) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0tdR-0006KY-G6 for qemu-devel@nongnu.org; Thu, 22 Oct 2009 05:07:05 -0400 Message-ID: <4AE02073.6030403@redhat.com> Date: Thu, 22 Oct 2009 11:05:55 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1256031192-8292-1-git-send-email-kwolf@redhat.com> <4ADD8D27.7090705@redhat.com> <20091022083156.GC27577@lst.de> In-Reply-To: <20091022083156.GC27577@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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Am 22.10.2009 10:31, schrieb Christoph Hellwig: > On Tue, Oct 20, 2009 at 12:12:55PM +0200, Kevin Wolf wrote: >> On that note, falling back to POSIX AIO means that paio_submit is called >> with a Linux AIO aio_ctx. Which works because this parameter is unused >> anyway, but am I the only one to find this ugly? >> >> What is the public interface of paio_submit meant to look like at all? >> If aio_ctx is guaranteed to be unused, why not drop it or pass NULL at >> least? And if it could be used some time in the future, the raw block >> driver needs to be fixed. > > Agreed. Cared to send a patch? Will do so if we agree to do it this way instead of doing the overkill suggested below. >> That said, I don't even think that the raw block driver is the right >> place to distinguish between different AIO variants. Having a generic >> aio_submit that calls the right AIO driver depending on the context >> would be much cleaner. This would also mean that laio_submit handles the >> fallback to paio_submit on its own, which I think is much cleaner than >> teaching raw about the capabilities of each driver. > > Seems a bit overkill until we get even more AIO variants at least. And > yes, that whole area is really ugly. 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? I'm not insisting on restructuring though if you think that the effort would outweigh the benefit of a cleanup. Kevin