From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kc5qr-0003Wx-5S for qemu-devel@nongnu.org; Sat, 06 Sep 2008 18:01:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kc5qn-0003VT-Gs for qemu-devel@nongnu.org; Sat, 06 Sep 2008 18:01:52 -0400 Received: from [199.232.76.173] (port=57050 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kc5qn-0003VH-Bw for qemu-devel@nongnu.org; Sat, 06 Sep 2008 18:01:49 -0400 Received: from ag-out-0708.google.com ([72.14.246.241]:3754) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kc5qn-0006mo-6J for qemu-devel@nongnu.org; Sat, 06 Sep 2008 18:01:49 -0400 Received: by ag-out-0708.google.com with SMTP id 31so2570794agc.5 for ; Sat, 06 Sep 2008 15:01:47 -0700 (PDT) Message-ID: <48C2FD9A.8010602@codemonkey.ws> Date: Sat, 06 Sep 2008 17:00:58 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Xen patches - status summary References: <18621.28008.90183.80897@mariner.uk.xensource.com> <48BEDAC3.8040109@redhat.com> <48BF4C46.2060101@codemonkey.ws> <18625.2823.334560.150430@mariner.uk.xensource.com> In-Reply-To: <18625.2823.334560.150430@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Ian Jackson wrote: >>>> The QEMU_ASYNC_EVENTLOOP change is a tidying up of the NBD feature to >>>> make qemu-nbd share more commonality with qemu-img. As discussed >>>> there are perhaps even more cleanups that could be done to improve >>>> this but as I say this change is a good start and should be applied. >>>> >>> Cleanups is, well, not the correct word IMHO. The complete block device >>> handling needs a major redesign. That this ifdef is needed in the first >>> place is a blatant layering violation. Also we should be able to >>> support async I/O in some form (be it libaio, threads or whatever) >>> without hacking support for it into each and every file format handler. >>> >> I have something queued up to help us get closer to this. That was an FYI, it wasn't about your patch. I agree your patch is a step in the right direction. Regards, Anthony Liguori